Last week we saw that using edeliver could drastically simplify our Elixir release process. Now that we can build and deploy our initial releases, we should investigate how edeliver can help us build, manage, and deploy upgrade releases.
To get a better idea of how upgrade releases work with edeliver, let’s make a change to our original application, build an upgrade release from that change, and then deploy that change to our production server.
Before we start building our upgrade release, we’ll need to make a configuration change to Distillery.
==> Upgrading prod from 0.0.1 to 0.0.1+82e2ed7 ==> Upgrade from 0.0.1 to 0.0.1+82e2ed7 failed: 0.0.1 does not exist at _build/prod/rel/prod/releases/0.0.1
Thankfully, we can change where these artifacts are stored with Distillery’s
output_dir configuration option.
rel/config.exs and set
output_dir to the
rel/<application name> directory:
set output_dir: "rel/hello_edeliver"
Now Distillery will store our release artifacts in
rel/hello_edeliver, which is where edeliver expects to find them.
Making Our Change
Let’s make a small change to our application. We’ll update our
index.html.eex and add a line indicating that we’ve upgraded the application.
At this point, we can either manually upgrade our application’s version in our
mix.exs file, or we can let edeliver manage our versioning for us.
Let’s keep things as hands-off as possible and let edeliver manage our application’s version.
At this point, we can commit our changes and move on to building our upgrade.
git commit -am "Added upgrade message."
Building and Deploying Our Upgrade
Elixir upgrade releases are always built off on a previous release. Distillery will generate a patch that changes only what is different between the old and new version of the application.
With that in mind, we need to know what version of our application is currently running in production. We can find this out using edeliver’s
version mix task:
mix edeliver version production
In our case, we can see that we’re running version
0.0.1 of our application in production.
Knowing that, we can generate our upgrade release. Upgrade releases are built with the
build upgrade mix task:
mix edeliver build upgrade --with=0.0.1 --auto-version=git-revision
We’re using the
--with flag to point to our previous
0.0.1 release. We’re also using the
--auto-version flag to tell edeliver to automatically handle the versioning of our application.
This command will generate an upgrade release with a version similar to
0.0.1+82e2ed7. You can see that the
git-revision option appended the current commit’s SHA to the end of the original release version.
Once our upgrade release has been built, deploying it to our production environment is a simple task:
mix edeliver deploy upgrade to production
That’s it! Our change was applied instantly to our running application with zero downtime.
If we check the version of our application running in production, we should see
mix edeliver version production
And lastly, when we view our application in the browser, we should see our upgrade message in the DOM.
After getting over a few configuration hurdles, using edeliver to build and deploy an upgrade release was a breeze.
Being able to seamlessly deploy an upgrade to any number of hosts with zero downtime is an incredibly powerful tool, and edeliver gives a polished interface for just this.
I’m looking forward to using edeliver more in the future.