Since for some strange reason people are still using Edeliver I suppose we can talk about what we want it truly to be.
During 2018 two things happen that in my opinion gives us more flexibility to reshape in a more user-friendly tool:
Distillery added appups
Edeliver supports only Mix now
Thus now it’s possible to focus on the core deployment tasks:
Building release
Storing it somewhere
Copying it to a designated servers
Updating/upgrading an app
From this perspective there are two questions that should be solved:
What are alternatives to bash scripting?
How we decouple environments and deployment targets?
As you can now Edeliver supports two environments - staging and production. That’s a very basic scenario. Here is a latest example where it simply doesn’t fit https://github.com/edeliver/edeliver/pull/301
I guess what we really want is to specify an environment and where (which hosts group) we want release to be deployed. Maybe also where it should be built.
What deployment guarantees do we want to achieve?
This is mostly about deployment to a multiple machines. What should happen if deploy fails? Do we want a retry or fallback mechanism for it? This might not be something of an immediate need but keeping it mind can be very useful since it can affect library design.
Please notice, that I’m not talking about deprecating Edeliver due to the respect to the amount of work that was invested into it and since it’s still being used despite being in decay state.
I feel like every reply to this post could be split off to a new thread debating bash.
I am using edeliver at the moment and honestly it just works and I don’t really have any complaints which is why I continue to use it. I don’t use upgrades always releases. Actually only complaint is the verbosity of the commands required to do a release.
mix edeliver build release && mix edeliver deploy release to production && mix edeliver restart production && mix edeliver migrate production
That is kind of a drag and I tend to just create a one liner shell script in each new project called like deploy with that in it.
Dream changes/questions(all are low priority):
I would like a way to signal that a build should be moved direct from the build server to the target hosts without downloading locally in the middle.
Interface with platforms to allow the dynamic generation of host lists based off like server tags or something.
Agree with @sanswork. It just works, and its setup is simple. I don’t use a lot of it, but it helps quite a bit. I wrap edeliver steps together with our own in one mix APP.deploy task.
These are not necessarily things that really need to become part of edeliver, but I think some of it could simplify deployment:
Have one single command that does the full release cycle (from build until target restart)
Easily make release building to happen in a local Docker (just reference a dockerfile and edeliver handles the rest?)
Delegate admin commands to other tools such as systemd (start/stop/…)
Enforce git tags matching Mixfile version (optional)
I have gone through several methods of deployments, some are still in use today. The easiest and most robust approach is actually writing scripts that executes Distillery on a build server and then manually “deploying” the compiled binary to my production servers. This works for low frequency deployments but it’ starting to hurt when you need more than one deployment per day.
Dockerised app is perhaps the easiest to automate deployment, but they came with some caveats, for example, I couldn’t do hot-code upgrades with them.
Edeliver has its drawbacks, but with a little tweaking, it simply works 99% of the time.
Honestly I don’t mind the bash scripts, but with Elixir we could probably build better error handling mechanism.
Honest question: What are prople using instead of edeliver? Pure distillery and some custom scripts to scp things and start releases? Docker? Bootleg?
We started with edeliver and while it never was my favorite and I believe it has some bugs (not generating a new vm.args for instance) it still seems like the easiest proven tool to get into.
We have a custom bash script wrapping it to make it a full one command to deploy. While I’m not super happy with it, it works and I’m unsure what to replace it with for what benefits.