<commit_before>### What We'll Need

There are just a few things we'll need before we continue.

- a working application
- a build environment - this can be our dev environment
- a hosting environment - this can be our build environment for testing/experimentation

We need to be sure that the architectures for both our build and hosting environments are the same, e.g. 64-bit Linux -> 64-bit Linux. If the architectures don't match, our application might not run when deployed. Using a virtual machine that mirrors our hosting environment as our build environment is an easy way to avoid that problem.

### Goals

Our main goal for this guide is to generate a release, using the [Elixir Release Manager](https://github.com/bitwalker/exrm) (Exrm), and deploy it to our hosting environment. Once we have our application running, we will discuss steps needed to make it publicly visible.

## Tasks

Let's separate our release process into a few tasks so we can keep track of where we are.

- Add exrm as a dependency
- Generate a release
- Test it
- Deploy it
- Make it public

## Add exrm as a Dependency

To get started, we'll need to add `{:exrm, "~> 0.19.9"}` into the list of dependencies in our `mix.exs` file.

```elixir
  defp deps do
    [{:phoenix, "~> 1.1.0"},
     {:phoenix_ecto, "~> 2.0"},
     {:postgrex, ">= 0.0.0"},
     {:phoenix_html, "~> 2.3"},
     {:phoenix_live_reload, "~> 1.0", only: :dev},
     {:cowboy, "~> 1.0"},
     {:exrm, "~> 0.19.9"}]
  end
```

With that taken care of, a simple `mix do deps.get, compile` will pull down exrm and its dependencies, along with the rest of our application's dependencies. It also ensures that everything compiles properly. If all goes well, exrm's mix tasks will be available.

```console
$ mix help
. . .
mix release           # Build a release for the current mix application.
mix release.clean     # Clean up any release-related files.
mix release.plugins   # View information about active release plugins
. . .
```

### Configure Our Applications

Now we need to update our `mix.exs` file to have all production dependencies listed in the `applications` list in the `application/0` function.

```elixir
  def application do
    [mod: {HelloPhoenix, []},
     applications: [:phoenix, :cowboy, :logger, :postgrex, :gettext,
                    :phoenix_ecto, :phoenix_html]]
  end
```

Doing this helps us overcome one of [exrm's common issues](https://hexdocs.pm/exrm/extra-common-issues.html) by helping exrm know about all our dependencies so that it can properly bundle them into our release. Without this, our application will probably alert us about missing modules or a failure to start a child application when we go to run our release.

Even if we list all of our dependencies, our application may still fail. Typically, this happens because one of our dependencies does not properly list its own dependencies. A quick fix for this is to include the missing dependency or dependencies in our list of applications. If this happens to you, and you feel like helping the community, you can create an issue or a pull request to that project's repo.

We also need to configure our Endpoint to act as a server in `config/prod.exs`.

```elixir
# Configures the endpoint
config :hello_phoenix, HelloPhoenix.Endpoint,
http: [port: 8888],
url: [host: "example.com"],
cache_static_manifest: "priv/static/manifest.json",
server: true
```

When we run `mix phoenix.server` to start our application, the `server` parameter is automatically set to true. When we're creating a release, however, we need to configure this manually. If we get through this release guide, and we aren't seeing any pages coming from our server, this is a likely culprit.

If we take a quick look at our `config/prod.exs` again, we'll see that our port is set to `8888`.

```elixir
. . .
config :hello_phoenix, HelloPhoenix.Endpoint,
http: [port: 8888],
. . .
```

Alternately, we can set the port from an environment variable on our system.

```elixir
. . .
config :hello_phoenix, HelloPhoenix.Endpoint,
http: [port: {:system, "PORT"}],
. . .
```

If we don't currently have such an environment variable, we need to set it now, otherwise our release will not build properly.
<commit_msg>Adds instructions to override the root path of the project in config/prod.exs so that static assets will correctly update during a hot upgrade.<commit_after>### What We'll Need

There are just a few things we'll need before we continue.

- a working application
- a build environment - this can be our dev environment
- a hosting environment - this can be our build environment for testing/experimentation

We need to be sure that the architectures for both our build and hosting environments are the same, e.g. 64-bit Linux -> 64-bit Linux. If the architectures don't match, our application might not run when deployed. Using a virtual machine that mirrors our hosting environment as our build environment is an easy way to avoid that problem.

### Goals

Our main goal for this guide is to generate a release, using the [Elixir Release Manager](https://github.com/bitwalker/exrm) (Exrm), and deploy it to our hosting environment. Once we have our application running, we will discuss steps needed to make it publicly visible.

## Tasks

Let's separate our release process into a few tasks so we can keep track of where we are.

- Add exrm as a dependency
- Generate a release
- Test it
- Deploy it
- Make it public

## Add exrm as a Dependency

To get started, we'll need to add `{:exrm, "~> 0.19.9"}` into the list of dependencies in our `mix.exs` file.

```elixir
  defp deps do
    [{:phoenix, "~> 1.1.0"},
     {:phoenix_ecto, "~> 2.0"},
     {:postgrex, ">= 0.0.0"},
     {:phoenix_html, "~> 2.3"},
     {:phoenix_live_reload, "~> 1.0", only: :dev},
     {:cowboy, "~> 1.0"},
     {:exrm, "~> 0.19.9"}]
  end
```

With that taken care of, a simple `mix do deps.get, compile` will pull down exrm and its dependencies, along with the rest of our application's dependencies. It also ensures that everything compiles properly. If all goes well, exrm's mix tasks will be available.

```console
$ mix help
. . .
mix release           # Build a release for the current mix application.
mix release.clean     # Clean up any release-related files.
mix release.plugins   # View information about active release plugins
. . .
```

### Configure Our Applications

Now we need to update our `mix.exs` file to have all production dependencies listed in the `applications` list in the `application/0` function.

```elixir
  def application do
    [mod: {HelloPhoenix, []},
     applications: [:phoenix, :cowboy, :logger, :postgrex, :gettext,
                    :phoenix_ecto, :phoenix_html]]
  end
```

Doing this helps us overcome one of [exrm's common issues](https://hexdocs.pm/exrm/extra-common-issues.html) by helping exrm know about all our dependencies so that it can properly bundle them into our release. Without this, our application will probably alert us about missing modules or a failure to start a child application when we go to run our release.

Even if we list all of our dependencies, our application may still fail. Typically, this happens because one of our dependencies does not properly list its own dependencies. A quick fix for this is to include the missing dependency or dependencies in our list of applications. If this happens to you, and you feel like helping the community, you can create an issue or a pull request to that project's repo.

Within `config/prod.exs` we need to make two changes.   First we must configure our Endpoint to act as a server `server: true`.  Additionally we must set the root to be `.`.

```elixir
# Configures the endpoint
config :hello_phoenix, HelloPhoenix.Endpoint,
http: [port: 8888],
url: [host: "example.com"],
root: ".",
cache_static_manifest: "priv/static/manifest.json",
server: true
```

When we run `mix phoenix.server` to start our application, the `server` parameter is automatically set to true. When we're creating a release, however, we need to configure this manually. If we get through this release guide, and we aren't seeing any pages coming from our server, this is a likely culprit.

When generating a release and performing a hot upgrade, the static assets being served will not be the newest version without setting the root to `.`.  If you do not set root to `.` you will be forced to perform a restart so that the correct static assets are served, effectively changing the hot upgrade to a rolling restart.

If we take a quick look at our `config/prod.exs` again, we'll see that our port is set to `8888`.

```elixir
. . .
config :hello_phoenix, HelloPhoenix.Endpoint,
http: [port: 8888],
. . .
```

Alternately, we can set the port from an environment variable on our system.

```elixir
. . .
config :hello_phoenix, HelloPhoenix.Endpoint,
http: [port: {:system, "PORT"}],
. . .
```

If we don't currently have such an environment variable, we need to set it now, otherwise our release will not build properly.

{'fraction_non_alphanumeric': 0.08628146833758456, 'fraction_numerical': 0.008650327159809248, 'mean_word_length': 3.853606027987083, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 21, 'https://': 4, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '7460507', 'n_tokens_mistral': 2610, 'n_tokens_neox': 2494, 'n_words': 1295}