Skip to content

The Release Process

Jump to bottom
Renato Mascarenhas edited this page Mar 29, 2016 · 1 revision

Concierge tries to follow, as much as possible, a somewhat semantic versioning. Even though, at this moment, Concierge's API is restrict to the format expected by Roomorama's webhooks, major changes on the application should reflect a major version upgrade; similarly, a small set of patches should cause only a patch-level update.

Development Process

New features/fixes developed on Concierge should be developed on feature branches, checked out from the development branch. Conventionally, such branches have the feature/ prefix (e.g., feature/new-supplier.) Branches are merged on development, tested on the staging environment and, periodically, merged back on master and made available on production.

The Change Log

The CHANGELOG.md file at the root of the project documents the set of changes that were introduced on each release. The goal is to keep a human readable list of all changes on Concierge and being able to quickly pinpoint when changes were added.

The change log format is inspired by the suggestions available at http://keepachangelog.com/. Read this page to understand how the log is to be organised.

Note that every pull request opened against development should have a meaningful, human readable list of changes being introduced, under the Unreleased section of the change log. This makes the release process easier since there is no need to check what is being added - it's all there.

Releasing a new version of Concierge

On every release, the following steps should be taken:

  • Create a new branch from development. Conventionally, such branches are named as release/<release-version>
  • Update concierge's version. It is declared at lib/concierge/version.rb.
  • The Unreleased section of the change log should now become the entry for the new release.
  • A pull request targeting the master branch from the release branch should be open.
  • Once tests on the staging environment succeed and it is time to deploy the new release on production, merge the release branch on master and create a new git tag. The tag should be named v<version>. Therefore, for the 1.2.8 release, a v1.2.8 tag should be created, pointing to HEAD on master.
  • Deploy the new release on production.
Clone this wiki locally