Heading image for post: How I Built My Own Heroku for Phoenix Apps: Part 3


How I Built My Own Heroku for Phoenix Apps: Part 3

Profile picture of Micah Cooper

Gatling's one major dependency, Exrm has been succeeded by Distillery. Here, we'll walk through considerations and implementation of replacing Exrm with Distillery.

Read part 1 here.

Read part 2 here

For more information on the motivations behind Distillery see here


Initally, there are two major considerations for this upgrade.

Backwards combatability

First thing to consider is backwards compatibility. Do I still want to support Distillery's predecessor; Exrm? Gatling could, in theory, inspect the project being deployed and break off into two separate paths- One for Exrm and one for Distillery. Another option is to release a major version upgrade (at the time of this blog post, from 0.1.0 to 1.0.0) and force users to upgrade to Distillery.

After reading through the Distillery docs and giving it a try, I decided to go with the latter option for a couple reasons: 1. I'm a big fan of keeping sofware up to date 2. This major change would require very little work from the client developer. He or she should only have to change the dependency in their mix.exs file.

Deployment Flexibility

Then next consideration is introduced by Distillery's added features. A user can do much more with a deploy including: - Building more customized releases - Adding boot hooks to a release - Adding custom commands to a release - Writing custom overlays for a release

See the Distillery docs for more details.

With all these new features, the questions is how much of these options should carry over to Gatling? Fortunately, just about everything. The goal of Gatling is to provide a convenient deployment strategy but still allow a user to customize whatever they want. Also, it just so happens most of these features don't really affect the way Gatling deploys a project.

How it's made

After thinking through the considerations, it's time to take some steps towards the and upgrade. The actualy code required to upgrade is minimal. I'd say the majority of the work comes from testing, and documenting the change for users:

The %Gatling.Env{}

The %Gatlng.Env{} struct is where we keep all the information (like paths, templates and modules) needed to perform a deploy. The upgrade required the addition of a few new things:

  • release_config_path - The is the location in the deploying project of Distillery's new config.exs file.
  • releases - This is a list of all the existing releases inside ./rel/. More on this later.

Mix Release

Exrm uses a mix task called mix release just like Distillery. The only difference here is one added step required by the additional features. Before gatling runs mix release, it must run mix release.init to generate a rel/config.exs file. So we simply add this to our pipline in the deploy and upgrade tasks:

def deploy(project) do
 Gatling.env(project, port: :find)
 |> call(:mix_deps_get)
 |> call(:mix_compile)
 |> call(:mix_digest)
 |> call(:mix_release_init)
 |> call(:mix_release)

And our mix_release_init/1 function looks like this:

def mix_release_init(%Gatling.Env{}=env) do
 if File.exists?(env.release_config_path) do
   log("#{env.release_config_path} found")
   bash("mix", ~w[release.init --no-doc],cd: env.build_dir)

Look for rel/config.exs file (the path is provided by our %Gatling.Env{} struct. If it's there, log that it was found, otherwise run mix release.init

Mix release --upfrom

The next change is in our mix gatlng.upgrade task. With Exrm, when we call mix release an upgrade release would be created automatically from most recent version. Now we do that explicity by finding the most recent release from our %Gatling.Env{} and calling mix release --upgrade --upfrom=<release>. The introductio of the Gatling.env.releases paves the way to much more than just upgrades. Eventaully, we may be able to use this upgrade and downgrade to any version. And also list out all the releases of our project.

The future

These are the major factors of upgrading Gatlig to use Distillery. It must be said that Distillery is still < 1.0 at the time of this writing. So, it would be fair to expect the changes of this new dependency to also affect Gatling. But that's ok. That's just part of the game. If you notice any bugs or issues with Gatling. Please add an issue in the tracker.

More posts about Deployment Elixir