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

Elixir Phoenix

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

Considerations

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")
 else
   bash("mix", ~w[release.init --no-doc],cd: env.build_dir)
 end
 env
end

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 Elixir Phoenix Deployment Heroku

  • Adobe logo
  • Barnes and noble logo
  • Aetna logo
  • Vanderbilt university logo
  • Ericsson logo

We're proud to have launched hundreds of products for clients such as LensRentals.com, Engine Yard, Verisign, ParkWhiz, and Regions Bank, to name a few.

Let's talk about your project