A rebar3 plugin for handling release upgrades. Supports the following features:

• Automatic generation of the .appup file containing instructions necessary to upgrade and downgrade from one release to the other. More info
• Validation of any .appup.src files that might be present, these are scripts that can contain Erlang code. They are templated, evaluated and their results and written to an .appup file that is then moved to the target dir. More info
• Handles any dependency .appup.src files maintained by your application. More info
• Automatic code injection for gen_server state record conversion between versions. More info
• Automatically generated module dependencies. More info

$ rebar3 compile

Add the plugin to your project's rebar.config:

{plugins, [rebar3_appup_plugin]}.

and the provider hooks:

  {provider_hooks, [
      {pre, [{tar, {appup, tar}}]},
      {post, [{compile, {appup, compile}},
              {clean, {appup, clean}}]}
  ]}.

By generating two releases, the one that is live right now and the one that we want to end up in. We can invoke the plugin and have it generate a special .appup file that OTP knows how to process in order to generate a release upgrade file (relup). This file contains low level Erlang VM instructions that will transition the Erlang application from one version to another without any downtime. More info.

You can generate the .appup file every time you pack a release with the rebar3 appup generate call. However when there is the need to add custom data or instructions to the .appup it's useful to have it in source control alongside your .app.src file. The .appup.src file can contain Erlang code and it's result should be a valid appup Erlang term. The plugin will look for any files ending in .appup.src, perform template variables substitution, evaluate them and have their results written to an .appup file that will then be used to generate the relup. More info.

When doing relups an issue that comes up often is the problem of ugprading the state record of your gen_server code. Most likely you have made some change that needs a new record structure alongside the code that handles it. OTP offers you the gen_server:code_change/3 call that enables state migration, this implies however that the new code must somehow know about the old record structure to migrate from. The plugin will automatically, by specifying a -state_record directive, inject the necessary code into the gen_server's .beam file that will take care of the migration. More info.

OTP allows the developer to manually specify the dependencies for each module in the .appup file, that is, which modules should be loaded before that one. The plugin takes care of this for you, by using xref it discovers which modules are being used and adds them to the relevant .appup entries. More info.

    Appup generator
    Usage: rebar3 appup generate

      -p, --previous    location of the previous release
      -c, --current     location of the current release
      -t, --target_dir  target dir in which to generate the .appups to
      -t, --target_dir  target dir in which to generate the .appups to
      -g, --purge       per module purge instructions, format is
                          [default | Module]=Purge | PrePurge/PostPurge
                        where Purge, PrePurge, PostPurge is either soft or brutal. Module is the name of a module in the .appup file, default is a reserved name to apply purge options
                        to unspecified modules.

rebar3 appup generate [--previous /path/to/previous/release] 
[--previous_version version] [--current /path/to/current/release] 
[--target_dir /path/to/target/dir] [--purge ]

• previous and current options should be full path names to the release (ie. the folder that contains lib/, releases/)
• current is optional and defaults to _build/<profile>/rel
• target_dir is optional and defaults to _build//rel//lib//ebin

rebar3 appup compile

rebar3 appup clean

Copyright (c) 2016 Luis Rascão

rebar3_appup_plugin source code is licensed under Apache 2.0.