I think it’s important to understand that deployment tooling has to integrate neatly into a very wide variety of environments and use cases, so I don’t agree that a nifty UI based tool is the primary solution (although having such a UI which consumes the underlying tools as a library might be really cool for those preferring that kind of thing). On the easy side, you have deploying to a VM/VPC, AWS/Azure/etc., where the tooling is simple and can be very flexible. Things are still fairly easy, but a little more constrained with deploying to services like Heroku, et al. Then you have people deploying releases via RPM or other package formats, perhaps installing in a VM and creating images for deployment to customer sites. Another group is deploying in an environment running Kubernetes, Mesos/Marathon, or OpenShift for example, and there are a lot of variables. How you deploy depends on whether you do blue/green, A/B deploys, or neither and just push the latest into service immediately. Luckily, Nerves has more or less solved the embedded side of things, so we don’t have to worry about that all that much, but the underlying tools still need to support Nerves. Right now that is Distillery, but if it became another tool, that tool would need to support other tools using some of the lower-level primitives to compose their own solution.
My personal take on this is that there is considerable room for improvement on the build side - making it extremely simple to build a deployment package for another platform, regardless of where you are building from. This should be exposed as one of the “primitives”, since some people will want to take that package and do their own thing with it. I think the build tooling should support generating container images, RPMs, etc., either through plugins or out of the box, making it trivial to choose the format you want to deploy with. On the deployment side, I suspect that those running container orchestration platforms like Kubernetes will use the tooling those systems provide to actually handle deployment, but having a flexible build tool will make it easy to integrate Elixir into the environment. In my own experience, working with Elixir under Kubernetes/OpenShift is already very easy, so there is not much else required here. For those deploying to VMs/VPC or AWS/Azure, this is where better tooling is most needed, and where most tooling currently sits. The biggest issue is that one needs a build machine which matches the target machine, more or less exactly. I suspect what Brian meant in his video is that Nerves allows you to build packages for a variety of hardware all from whatever machine you are currently using, via buildroot and a cross-compilation toolchain. If we could do something similar for general Elixir deployment, it would be a huge improvement over the situation today, as it would alleviate the vast majority of issues newcomers experience. Once you get beyond building a release and getting it to a target, the rest is actually quite pleasant with Elixir. There are still some rough patches with regards to configuration and differences between Mix and releases, but those gaps are closing, slowly but surely. I suspect being able to focus on the problem full-time, these too can be solved more elegantly.
