edeliver | Deployment for Elixir and Erlang | Authentication library

Assuming an Elixir project, you already have a build server and a staging server, and you've created a database on your staging server already (there is no ecto.create, we skip straight to migrations).
Because it is based on deliver, it uses only shell scripts and has no further dependencies except the Erlang/Elixir build system.
mix in conjunction with distillery for elixir/erlang releases (recommended)
mix in conjunction with relx for elixir/erlang releases
rebar3 for pure erlang releases or in conjunction with rebar_mix plugin to build also Elixir sources and dependencies
rebar for legacy pure erlang releases
If a ./mix.exs and a rel/config.exs file exists, mix is used fetch the dependencies, compile the sources and distillery is used to generate the releases / upgrades.
If a ./relx.config file exists in addition to a ./mix.exs file, mix is used fetch the dependencies, compile the sources and relx is used to generate the releases / upgrades.
If a ./rebar.config file exists but no ./relx.config, rebar3 is used to fetch the dependencies, compile the sources and to build the release
Otherwise rebar is used to fetch the dependencies, compile the sources and generate the releases / upgrades. It is recommended to migrate to rebar3 in that case.
For build commands the following configuration variables must be set:. The built release is then copied to your local directory .deliver/releases and can then be delivered to your production servers by using one of the deploy commands. If compiling and generating the release build was successful, the release is copied from the remote build host to the release store. The default release store is the local .deliver directory but you can configure any destination with the RELEASE_STORE= environment variables, also remote ssh destinations (in your server network) like RELEASE_STORE=user@releases.acme.org:/releases/, amazon s3 locations like s3://AWS_ACCESS_KEY_ID@AWS_SECRET_ACCESS_KEY:bucket or as a docker image like docker://edeliver/echo-server. The release is copied from the remote build host using the RELEASE_DIR= environment variable. If this is not set, the default directory is found by finding the subdirectory that contains the generated RELEASES file and has the $APP name in the path. e.g. if $APP=myApp and the RELEASES file is found at rel/myApp/myApp/releases/RELEASE the rel/myApp/myApp is copied to the release store. To build releases and upgrades faster, you might adjust the GIT_CLEAN_PATHS variable in your config file e.g. to something like ="_build rel priv/generated" which defaults to .. That value means, that everything from the last build is reset (beam files, release files, deps, generated assets etc.) before the next build is started to ensure that no conflicts with old (e.g. removed or renamed) files might arise. You can also use the command line option --skip-git-clean to skip this step completely and in addition with the --skip-mix-clean option for full incremental builds.
APP: the name of your release which should be built
BUILD_HOST: the host where to build the release, or "docker" to build in a docker container
BUILD_USER: the local user at build host
BUILD_AT: the directory on build host where to build the release. must exist.
Builds an initial release that can be deployed to the production hosts. If you want to build a different tag or revision, use the --revision= or the --tag argument. If you want to build a different branch or the tag / revision is in a different branch, use the --branch= argument.
If BUILD_HOST is set to "docker", edeliver builds the release in a docker container instead of building on a build host. It uses the docker image set as DOCKER_BUILD_IMAGE which defaults to elixir:1.13.3 with erlang 24, but can be overridden in your .deliver/config. When building in a docker container, the git repository to build is pushed to the local dir .docker-build which is then mounted into the container and edelivers build commands are executed as docker exec commands in the container.
If RELEASE_STORE is a (private) docker image in a docker registry like docker://edeliver/echo-server the built release will be embedded into a docker image based on DOCKER_RELEASE_BASE_IMAGE (which defaults to edeliver/release-base:1.0) and pushed with that image name from the RELEASE_STORE to your registry (if --push is used). It creates (and optionally pushes) three image tags: release version + latest, release version + git sha and release version + branch. The release can then be started on a host authenticated at the same docker registry like this:.
Builds an upgrade package that can be deployed to production hosts with running nodes without restarting them. To build an upgrade package you need the release or upgrade package (when using distillery) of the running release. If it is available (in the release store), you can build the upgrade to the new version by passing the old version to the --with=<old-version> option. If not, you can build the old release and the live upgrade from it in a single step by using the --from=<git-tag-or-revision> option. If you don't want to build an upgrade to the current head of the given branch (master is the default), you can use the --to=<git-tag-or-revision> option. If the upgrade package is built, you might want to modify the generated upgrade instructions (relup) as described in the next section or (more advanced) automatically patch the relup file by implementing your own Edeliver.Relup.Modificationbehaviour to automate this step.
From the auto-generated appup instructions of all included and updated applications, a relup file is generated during the build upgrade command and included in the upgrade package. It contains the upgrade instructions for the new release version. If there are dependencies between modules or applications, it might be necessary to modify this file, e.g. changing the order of the applications or modules that are reloaded. If there are repeating steps to adjust the relup for your application, you can automate this step by implementing your own Edeliver.Relup.Modification behavior.
To build upgrades, there must be only one release in the release directory (rel) of your project as configured in your rebar.config. E.g. if you want to build two different releases project-dir/rel/release_a and project-dir/rel/release_b you need two rebar.config files that refer only to either one of that release directories in the sub_dirs section. You can then pass the config file to use by setting the environment REBAR_CONFIG= at the command line. The reason for that is, that when the upgrade is build with rebar, rebar tries to find the old version in both release directories.
Deploys an upgrade at the production hosts and upgrades the running nodes to the new version. This requires that the build upgrade command was executed before, and that there is already an initial release deployed to the production hosts, and that the node is running. Release archives in your release store that were created by the build release command cannot be used to deploy an upgrade. This command requires that your release start script was generate by a recent rebar version that supports the upgrade command in addition to the start|stop|ping|attach commands. Releases generated with mix and distillery always contain the upgrade command.