My experience is that preparing a release is much more straightforward since Elixir 1.9, which added release support to the Elixir standard distribution. That said I tend to treat a release as a black box, I haven't tried to understand what all those files are and I just interact with bin/myapp.
However I still have two complaints.
First, the system on which the release is built and the system where it's going to run need to be similar (same version of the same Linux distribution). In practice this means that these days we build releases in containers matching the target host.
Second, releases can't run mix commands so we have to write boilerplate code specifically for releases for things like database migrations, etc. It would be nice if writing app management commands could be a bit more DRY.
I could be wrong but at first glance it doesn't seem that Bakeware addresses these issue.
You can actually get away with quite a lot in terms of mismatching platforms. We target an embedded system (Xilinx Zynq). We cross compile the Erlang+Elixir system into the Linux platform build. Then for the application code we just build the release using no_erts. We're building that application on X86, just making sure that the Erlang/OTP/Elixir versions match and it works.
We have some ports that are separately cross-compiled and provided on the target.
+1 on the issue of Mix commands. We also put in boilerplate code for database migrations, but eventually I decided this was stupid. Now I keep the source on the servers and just run Mix commands from there.
Since migrations are idempotent, and I always want to run up to the latest migration, I just include this in lib/myapp.ex in its start function. That way any time a new release rolls out, the first node with the new release automatically runs the migrations. (We always make sure our migrations are backwards compatible for at least X number of versions, which means never deleting tables or columns so that existing nodes don't break)
But then you need to install Erlang/Elixir on the server, which kind of defeats the purpose of releases, don't you? Or have you abandoned releases altogether?
I actually find really good that mix commands are not included.
Those are Makefile commands, I wouldn't expect them on production.
It's funny that the case highlighted is the one about migrations, which indeed shouldn't be located or connected to the app in the first place. There are a lot of SQL migration tooks available, but even simple bash scripts are enough.
Releases should be able to use Mix commands. You might need to adjust your mix deps to include Mix/Ecto-Migrator libraries for your build. Otherwise you can do what people use for sqlite3 migrations in Nerves [1]. Just call it via the library functions instead of via the command line like in `migrate_repo!/1`.
However I still have two complaints.
First, the system on which the release is built and the system where it's going to run need to be similar (same version of the same Linux distribution). In practice this means that these days we build releases in containers matching the target host.
Second, releases can't run mix commands so we have to write boilerplate code specifically for releases for things like database migrations, etc. It would be nice if writing app management commands could be a bit more DRY.
I could be wrong but at first glance it doesn't seem that Bakeware addresses these issue.