Erlang releases best practices?

Question

I am Erlang noob, and I tested Faxien + Sinan and Rebar, and the main philosophy of Erlang OTP seems to be to install applications and releases on a single instance of an Erlang image. What are the best methods for storing standalone versions? Is there a way to pack releases so you don’t have to change the site for the machines you are deploying to? How about collecting all the dependencies in the code base for management?

Perhaps I am going to go against the grain ... I come from the Java background, and the philosophy of "nothing predefined, but the JVM" seems completely different.

Answer 1

IMHO this cannot be answered in a few sentences. You need to read some parts of the attached documentation, especially the Erlang / OTP Documentation (otp-system-documentation-XYZpdf, with XYZ the version number), or look at the Erlang and OTP in Action book, because throughout this the book is a “one” example of a “service” with different “parts” from the first steps, using the Erlang / OTP concepts and finally creating the “release”.

IMHO, this is currently the best book because it not only introduces Erlang, but also shows what OTP is and how OTP is used for the project. And this is not just a collection of free samples, but everything is built around one project.

Answer 2

I will describe the approach that currently works for me for regular (often daily) releases for a small number of instances on EC2:

• I installed my project with fixtures and tested it on github.
• All my dependencies are listed in my rebar.config file (they are also on github).
• My Makefile is similar to what I described here .
• My EC2 image only has a standard erlang build and no other libs installed by default.
• To create a new node, I deploy the instance, clone my git repository and run make . This will get my addictions and build everything.
• To update the code, I do git pull and rebar update-deps . Depending on what has changed, I can restart the node or, often, I will connect to a working node and reload the updated modules. This helps to run and attach scripts as part of your project.

It may be useful to see how a project is packaged, such as webmachine .

I don’t know much about the standard OTP release management system, except that it looks like a lot of work. Since this seems to run counter to rapid deployment, I have never experienced a serious attempt - although I am sure it makes sense for other projects.