Release Process
5 minute read 23 May 2016

This guide is for developers and non-technical users alike who are involved in the Release Process and explains:

  • what a typical Site Stacker setup looks like
  • how changes become available on a sandbox environment
  • how to create releases and add information for the client
  • how to install and test new releases on a test environment
  • how to edit the release notes for an existing release

Prerequisites

First of all, you should be familiar with the Branching and Release Workflow guide. Also this guide assumes all repositories and servers involved were properly configured by a developer. This includes:

  • all repositories have one stable release branch (e.g. 2.x) and one “next” release branch (e.g. 2.next)
  • System Manager is configured correctly to track a release branch and Is Sandbox is ON only on the development server

A typical Site Stacker setup

A typical Site Stacker setup includes 3 servers:

  1. Development (Sandbox) Server
  2. Test (Staging) Server (optional)
  3. Production Server

In System Manager, the three servers are configured as follows:

Server Branch Filter Is Sandbox
Development (Sandbox) 2.x 2.next :heavy_check_mark:
Test (Staging) 2.x 2.next  
Production 2.x  

Development (Sandbox) Server

Developers are responsible for making available the changes they work on by merging in development branches into release branches. In our example, development branches are merged into next as features are ready to be released at the next release cycle and next is merged into 2.next to make the changes available.

After the changes are pushed into a release branch, they become available immediately on the development server, without needing to create a tag.

Dev Update

Create release

Once you’re satisfied with the changes, you can create a release. The easiest way is from System Manager on the development server, using the Create release button:

Create Release

Note: When you create a release in this way, you can be sure that the release will only contain the changes that were already installed on this server, and nothing else.

If you don’t use the Create release button from System Manager, you’ll have to enter the commit hash manually in the Create from field in GitLab.

Create a tag in GitLab

After clicking on Create Release button in System Manager, you’ll be taken to the New Tag screen in GitLab where you should enter:

New Tag

Note that the Release notes section is ignored because that information is only stored in GitLab’s database.

Tag message

The tag message is optional and can contain additional information that the client will see when updating in System Manager. There’s no need to reiterate here all the changes in the release, because this is done automatically based on commit messages, as explained in the Changelog.

The tag message can contain references to any external materials, etc. so the client knows what to expect when updating.

Test Server

Once a tag is created, it will become available on the installations that have that release branch configured in System Manager. In our example, it will become available on the development and test servers.

Update on Test

At this point the release can be tested on the test server and, if everything is ok, the production server can be updated when the release lands in the stable release branch (e.g. 2.x). If issues are found, the developers should fix them and the release process will restart.

Production Server

Once the “next” release branch (2.next) is merged into the stable release branch (2.x) at each release cycle, the releases become available on the production server.

Edit release

To edit an existing release, you need to delete the tag and create a new one in place.

Find existing tag

You first need to find it. You can use the View release button in System Manager on the development server or you can search for it on GitLab.

View Release

Add a new tag in place

After you find the tag, you should click on the commit hash and copy it to clipboard as follows:

View Commit

Copy Commit

Now that you have the commit hash copied to clipboard, you can create the new tag using the GitLab interface:

New Tag

Paste the copied commit hash in the Commit from field and then follow the steps for creating a release in GitLab. You might want to also copy the message from the existing tag.

Delete existing tag

Back to the existing tag, you can now safely delete it from GitLab:

Delete Tag