You’ve got two options: Hot code load, or rolling deploy. In the hot code loading method you use one of Erlang’s unique features whereby you can simply replace the code that was running with new code, and there are some hooks for how to migrate data. The challenge with this approach is that not only do you need to think about migrating database data, any data you have in memory needs to be migrated as well, cause it’s straight up replacing old code with new code without stopping. Notably you need to use distillery releases for this, mix releases don’t support hot code loading.

Rolling deploy is more traditional, and it’s how you solve this in any other language too. In this method need more than 1 server running, and a load balancer that directs traffic to your nodes. You tell the load balancer to stop sending traffic to node A, then you have node A stop the old release, then start the new release. Then you direct traffic back to A, and move on to the next node. Any database migrations need to be compatible with both versions of your code since you’ll have a period of time while both versions are running.

The actual mechanics of how this is accomplished depend on how you’ve got your servers setup and how you have your load balancer(s) setup. There are also variations where you start brand new servers (or docker containers) that run the new version, migrate traffic over, and then delete the old servers (or docker containers) running the old versions.

You can’t do out of the box hot code upgrades with 1.9 releases, so your best option is to handle it with a load balancer. One way to do this is to make a blue-green deployment setup. It’s similar to what @benwilson512 says, you start up node b, when it’s running then switch your load balancer (e.g. nginx) to direct traffic to node b instead of a, and then shut down node a when all traffic has been redirected. This all happens on the same server.

You will have to set up you ansible playbook so it’s aware what port/socket each node runs on, and can switch between them during deploy. I’ve had plans for a while to expand on my Ansible guide with blue-green deployment, but have had no time to dig into it.