Thoughts about Edeliver 2.0

lessless

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 Add support for multiple production environments by meox · Pull Request #301 · edeliver/edeliver · GitHub
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

14 comments

#library #edeliver #deployment

6 3327 14

2019-01-30 09:35:46 UTC

Showing Posts 1 to 10

Show Best Posts
Show All (oldest first)
Show All (newest first)

romul

Ruby, Python, Elixir itself.. Everything is better than bash scripts

Post #1

OvermindDL1

Not always, bash scripts are succinct, readable, and load fast. ^.^

Post #2

lessless

I guess we can rewrite most of the BASH scripts through the Mix Tasks

Post #3

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.

Post #11

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)

Post #12