lessless
Thoughts about Edeliver 2.0
Hi guys,
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.
Let’s get a good discussion folks 
Most Liked
OvermindDL1
Not always, bash scripts are succinct, readable, and load fast. ^.^
sanswork
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.
Failed deploys should rollback in my opinion.
lessless
I guess we can rewrite most of the BASH scripts through the Mix Tasks
rodrigues
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)
PragTob
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.







