There a lot of materials describing the strengths of the Elixir, but, unfortunately, deployment is not one of them yet. And that, in my opinion, neglects the overall value of every other positive thing about it, because of not being able to reliably operate in production is putting it in the “nice to play with” corner and holding back its wider adoption.
I’m not sure I agree with this really. I definitely want to continue to improve the tooling, because it certainly has plenty of room for improvement, but I do think that where we are at is a lot better than many other platforms. I’m not going to comment on edeliver here because I don’t really know much about it beyond the basics - it doesn’t fit the various deployment models I’ve used since I started using Elixir professionally. That said, the underlying tech - OTP releases - is extremely solid, and I can’t think of any other platform that gives you the level of runtime operational tooling that they provide - it’s certainly way beyond “nice to play with”. It may sound like I’m patting myself on the back here, but exrm/distillery made it super easy to build releases in Elixir - in many cases all you need to do is run MIX_ENV=prod mix release and you have your deployment package - it’s not as simple as building static binaries, ala Go, but it’s still very painless.
Even in my current situation, where we are building releases, then composing an rpm package for installation, we are able to use pretty much the basic features of distillery + a single thin custom command to expose an interface for a shell script which acts as the CLI tool for interfacing with the application - and we do a lot of things with that.
Migrations, much like hot upgrades, are extremely tricky to get right - I would go so far as to say there is no general solution which will “solve” that. You may have multiple backend datastores which need schema updates, configuration changes, etc., which are non-trivial to roll-back (or perhaps even non-trivial to roll out in the first place). Your primary application may need complex appups to be hand written in order to do hot upgrades (if you are leveraging those in tandem with migrations). The story in Elixir around this is no different than any other language in my opinion, but you do have hooks at pretty much every stage of the deployment process to attempt to do these things with your own code.
There are definitely things that are left up to the consumer of tools like Distillery right now, and which might make it seem like there are warts, for example:
- You need to be sure to set up your build environment so releases are built on the same OS/architecture as your prod environment. If you already have such infrastructure, this is basically a non-issue, but if you are trying to build on your laptop and deploy to DO or something, then there is some extra work involved (e.g. setting up Vagrant/Docker or something).
- You have to understand the differences between Mix configuration and the static configuration used by releases (
sys.config), and make sure you accommodate those differences. This is well documented, and there are a number of approaches, but it does mean things aren’t necessarily as easy as dropping in the tool and building a release.
- There is no one-size-fits-all approach to doing migrations, because as I mentioned above, I don’t believe one is possible, and I prefer making it possible to layer on your own code to handle this and providing all the hooks necessary to do so. However there is official documentation on one way to handle them with Ecto, and a number of different approaches documented in the wild.
TL:DR - I don’t think the current state of deployment in the Elixir community is as dire as you make it out to be; but I do agree that there is plenty of room for improvement, more tooling which is more prescriptive which can make lives easier for those doing similar types of applications, and definitely more and better guides and documentation on how to get started and how to handle more advanced scenarios. I’d also like to add my voice to the plea for contributors to tools like edeliver (and selfishly, Distillery ;)), because contributions keep things moving along when maintainers like myself get swamped with their actual jobs, not to mention the myriad other things which distract from our open source work.
The worst part about it is that it isn’t actively maintained and there are 15 PRs in the queue.
if you are running a proper RDBMS (pg) you could do atomic migrations but beyond that …
