I'm in agreement with @DianaOlympos, @talentdeficit, @wmnnd, and @bitwalker here. Creating a new "deployment tool" specific to the Elixir ecosystem seems like it's a solution in need of a problem.
When I first started using Elixir, I often heard that deployment was an issue, and I started repeating that as if it was a mantra. The company I worked with at the time started by deploying to Heroku, and that worked well for our purposes. I moved companies, and my current company was also deploying Elixir to Heroku. As our needs grew, I learned how to build releases with Distillery. I put together a deployment pipeline using non-Elixir tools and started shipping releases from our build servers through to staging and production.
And now I question what this "deployment is an issue" comment really means.
Right now my team uses AWS CodeDeploy for deployment purposes. A release artifact (built using Distillery) is bundled with rules for CodeDeploy's engine. The bundle is pushed to S3 from our build server and registered with CodeDeploy. Our current setup requires manual triggering of a deploy, and we currently use the CodeDeploy UI for that. We utilize the same bundle for both staging and production. Our system loads as much of its configuration as possible at runtime via environment variables.
I don't solve deployment using Elixir focused tooling. I use generic tooling because it's a generic problem. I could use the same tools now with Go, Java, C#, etc.
I could also build it into an AMI using Packer, seal it into a Docker image, scp it to a fleet of servers using Ansible, bundle it into a .deb…there's a list of generic tools that solve these issues.
What I think we need is more documentation around best practices for building releases, managing runtime configuration, integrating with existing infrastructure tooling, and incorporating operating concerns into our codebases and executables. That's what I'm picking up from this conversation and other conversations I've had in the community.
From what I can tell, people want/need:
- A clearer picture of why to use releases and why running in production via
mix is not best practice
- Guidance on runtime configuration management (and particularly helping package authors write configuration-system agnostic packages)
- More information about taking a release and running it on Ubuntu/Amazon Linux/Docker/K8s/the back of a turtle; this includes how to publish the release to the unit, write startup scripts, redirect logs to files or services, manage starting/stopping the release
- Expanded guides on building operations logic into the codebase and releases (e.g., performing Ecto migrations without
mix, and other things one normally would have made a
rake task or the like for)
If someone asks you, "Now that I've built it, how do I launch it?" they're looking for instructions. That doesn't mean another tool is necessary.