ConfiguringMultipleReleases

Configuring Multiple Releases in the Same Project

Introduction

Sinan has the ability to have multiple Erlang releases all created from the same project. This allows you to work on code in unison but release sub-parts of the project as needed. It also allows you to have multiple configurations for the same project. This may be useful if you would like to have a release that contains debug information and one that does not. We will explain how to do this shortly. To get started though lets look at the example project that we will use.

The Example Project

We have a project called foo and for various reasons we need to create four releases for that project; r1, r2, r3, and r4. Inside this project are four applications; app1, app2, app3 and app4.

Release Organization

Release r1

Release r1 will include app1, app2, and app3. It will also include debug_info for all apps in the release.

Release r2

Release r2 will include app2 and app3. It will include debug_info as well but only for app2.

Release r3

Release r3 will include app1 and app3.

Release r4

Release r4 will only include app4. Release r4 will also include the erts runtime as well.

Building Different Releases

Your project has a built in release that is the same name as your project. This release is always available and is always the default release if no release is specified. In our example project the default release is foo and we can build the foo release by simple doing:

$> sinan build

How do we build the other releases though? Well we have to tell sinan what release to build. We do that by passing -r <release-name> on the command line with the build. For example, if we wanted to build release r1 we would do the following:

$> sinan -r r1 build

That informs sinan which release to build.

The sinan.config

The sinan.config is the key to all of this. Lets start by getting the header out of the way:

{project_name, foo}.
{project_vsn, "0.2.0"}.

Release r1

Now we things start getting interesting. Lets start by configuring our r1 release.

{{dep_constraints, [{release, r1}]},
  [{exclude, app4}]}.

{compile_args, [{release, r1}],
 [debug_info]}.

There are two things to notice in this example. The first is the second element in our configuration tuple. That second element is list of specializers. It takes the configuration tuple and specializes it to the target. There are four specializations you can make use of; task, release, app, and module. This allows you to specialize a bit of configuration right down to the module. In this case we are specializing on a release and so only need a single specialization tuple in that specialization list.

The second thing to make note of is the exclude option in the dep_contstraints. This is how we exclude applications from consideration by the system. This works for apps in the project or for apps that are primary and tertiary dependencies of applications in the project. In the case of release r1, we want to retain app1, app2 and app3 so we exclude app4.

Finally because this is a debug release, we include debug_info, specializing the configuration on this release.

Release r2

Release r2 is similar to r1, with the exception that we will exclude both app1 and app. We will also specialize the debug_info compile option to both release r2 and app2.

{{dep_constraints, [{release, r2}]},
  [{exclude, app4},
   {exclude, app1}]}.

{compile_args, [{release, r1}
                {app, app2}],
 [debug_info]}.

Release r3

Release r3 is very similar to release r2 with no additional configuration.

{{dep_constraints, [{release, r3}]},
   [{exclude, app4},
    {exclude, app2}]}.

Release r4

Finally we hit release r4 where we want to exclude everything but app4 and also include the erlang runtime in the distribution tarball.

{{dep_constraints, [{release, r4}]},
  [{exclude, app3},
   {exclude, app2}
   {exclude, app1}]}.

{{include_erts, [{release, r4}]}, true}.

The Final Configuration

At the end our configuration file looks as follows:

{project_name, foo}.
{project_vsn, "0.2.0"}.


%% Release r1
{{dep_constraints, [{release, r1}]},
  [{exclude, app4}]}.

{compile_args, [{release, r1}],
 [debug_info]}.

%% Release r2
{{dep_constraints, [{release, r2}]},
  [{exclude, app4},
   {exclude, app1}]}.

{compile_args, [{release, r1}
                {app, app2}],
 [debug_info]}.

%% Release r3
{{dep_constraints, [{release, r3}]},
   [{exclude, app4},
    {exclude, app2}]}.

%% Release r4
{{dep_constraints, [{release, r4}]},
  [{exclude, app3},
   {exclude, app2}
   {exclude, app1}]}.

{{include_erts, [{release, r4}]}, true}.