This document is part of overall engineering release workflow.
Going forward, patch release (MAJOR.MINOR.X) would describe release that is being created as a follow up to a set of releases made in the run-up to the 22nd of the month (MAJOR.MINOR.0). All RC and final MAJOR.MINOR.0 will be referred to as releases.
See also terminology overview.
Releases are a mix of manual tasks driven through a checklist and automated processes to create release artifact and deploy to GitLab.com environments.
The process can be broken down into:
masterbranch is created and named
stablebranch in GitLab Rails Community Edition repository. The stable branches are created when the release process starts
masterbranch in sync with an automated CE to EE merge job
stablebranches multiple times until the code freeze
*_VERSIONfiles located in GitLab Rails repository and update the omnibus-gitlab repository
takeofftool. This tool will trigger the package installation, followed by configuring and restarting services based on a set of rules
The release turnaround time varies between 12 and 24 hours. In cases where an issue is discovered during any of the mentioned steps, we can have days of delay before the change is applied to environments. This overview does not include situations when GitLab environments require an urgent hot-patch, or security patch.
Few conclusions can be drawn from the above:
To address the process above without starting from scratch, we should be looking into a plan that would remove most of the manual work first, and open up more time for us to work on the next step.
As an immediate step, we need to remove the need for most manual actions. Engineers tasked with release should only need to trigger the start of the process, and then have control over deployments that are user facing.
To do this, we need to leverage GitLab as a tool together with ChatOps.
Release would look as follows:
Once the above is achieved, we will expand on each of the steps.
Few items worth considering: