Support Distillery

[bitwalker]

Hey guys, great project!

I would recommend you target Distillery instead of Exrm at this point, is there anything I can do to help?

[mrmicahcooper]

Hey @bitwalker,

Thank you! Yes, I've started looking into Distillery. It seems like it's a lot faster and has a lot more features. This is very exciting!

It appears Distillery's default location for a release is the same as Exrm. So, I'm thinking an initial upgrade path would look something like:

• Instruct Gatling user to Install Distillery instead of Exrm
• Gatling would run mix release.init before the initial release
• On an upgrade, Gatling would run mix release --upgrade instead of just mix release

Does that seem about right?

Also, I have a question for you. What are your thoughts on not requiring a Gatling user to install Distillery at all?

If Distillery was installed alongside Gatling (possibly as an archive) and Gatling could simply call something like mix release --input=path/to/elixir/app --output=path/to/release.

This would allow a user to deploy an application to a server with no added dependencies to their project. Though the user could optionally add their own /rel/config.exs which would override the defaults generated by the server.

[bitwalker]

Yep those steps look good :)

It's possible I could support this, I haven't actually looked into consuming the task from an archive at all, since Distillery is heavily dependent on the current Mix context for the project being released. The primary problem I see with it, is that as of today, users need to be aware that they are using releases, since there are a few caveats to them (handling of runtime configuration primarily). Abstracting that away means they are bound to make mistakes, at least until such time as we can make that a non-issue with releases, but there are some difficult problems to solve there yet. So I think it makes sense to make it explicit that they are depending on Distillery, at least at this point in time. The library is not bundled into releases, so it adds no additional at runtime, it just means an extra dependency.

I like the idea of moving in that direction though, I basically want to achieve exactly what you are suggesting - users don't need to know that they are deploying a release, it just works. I doubt we'll ever get to a point where we can do that with hot upgrades involved, but for standard rolling deploys, I think we're definitely within reach of it.

[mrmicahcooper]

Great. I've started taking the above approach.

I definitely see what you're saying about the hot upgrades. After reading your docs I see that it's much more involved.

Thank you for the the feedback and suggestion. I'll close this ticket upon the update to support distillery.

[bitwalker]

Sounds good! Feel free to reach out with any questions or comments, I'm in IRC quite often as well if you need to reach me for a quick conversation.

[mrmicahcooper]

@bitwalker I just released a 1.0.0 that uses Distillery. It's pretty great. I'm sure there will be some changes as Distillery hits 1.0.0. I look forward to getting those in.

Thanks!

[bitwalker]

@mrmicahcooper That's great! Just an FYI, but there is one major change coming (it's already in master, and will be in 0.11), the default path for release artifacts will now be _build/$MIX_ENV/rel/<release_name> instead of rel/<release_name>. This can be controlled with the output_dir setting in rel/config.exs, but that setting itself is new and not backwards-compatible, so you may want to require a certain version of Distillery when it's properly released, or check the version being used with Application.spec/1.