Deployments and Releases

Overview and terminology

This page describes the deployment and release approach used to deliver changes to users. The overall process consists of two significant parts:

1 Monthly self-managed release: GitLab version (XX.YY.0) published every month. From this monthly release, patch, non-critical, and critical security releases are created as needed 1 GitLab.com deployment: A Continous Delivery process to deploy branches created from master branch, on regular intervals.

For more details on the individual processes and how to use them please see the Deployments page for GitLab.com changes and the Releases page for changes for self-managed users.

The main priority of both deployments and releases is GitLab availability & security as an application running on both GitLab.com and for users running GitLab in their own infrastructure.

Deployment and Release Process overview

For testing purposes, all changes are deployed to GitLab.com before being considered for a self-managed release. Deployment and release cadences operate on different timelines with changes deploying to GitLab.com multiple times per day, and packages being released for self-managed users several times a month.

This overview shows how the two processes are connected:

• Diagram source

1. Engineer creates features or bug fixes. Changes reviewed by Maintainers
2. Validated changes merged into the default branch
3. A scheduled pipeline packages all new changes into an “auto-deploy package” for deployment to GitLab.com. Multiple packages are created each day at the listed times
4. If deployments are allowed the auto-deploy pipeline starts. Production Change Locks, unhealthy environments, or other ongoing deployments are examples of events that would prevent a deployment
5. The auto-deploy package is deployed to GitLab.com. For more details see the deployment process
6. Changes that have been successfully deployed to GitLab.com can be considered for packaged release for self-managed users. A new release candidate package is created for these changes
7. The release candidate is deployed to a test environment and automated QA tests execute
8. Release Candidate is officially tagged and published for release

For a more detailed explaination of the processes see the deployments page and the releases page

Release Managers

The overall coordination and operation of the deployment and release process is the responsibility of the release managers.

See the GitLab Release Managers schedule to find out who the current release managers are.

How to contact a Release Manager

You can contact the current Release Managers:

1. On GitLab issues and epics by using @gitlab-org/release/managers handle
2. On Slack by using the @release-managers handle

We use the #releases and #f_upcoming_releases channels to discuss and coordinate deployments and releases. Automated deployment status announcements are made to the #announcements channel.

If you need to escalate a request, please use the release management escalation process

Weekly Delivery Metrics Review

Each week, the current Release Managers walk through the key Delivery Group metrics in the EMEA/AMER Delivery Weekly sync (YouTube Playlist). The goal is to share experiences about recent deployments and releases, and for the Group to identify ways we can improve our tools and processes.

MTTP Monthly - Deployment blockers - Deployment SLO - GitLab: deployment frequency - GitLab: lead time

1. Walkthrough Auto-Deploy packages dashboard
2. Walkthrough the monthly view of GitLab: deployment frequency and GitLab: lead time - note any patterns
3. Walkthrough of last week’s Deployment Blockers
4. Do we need to take action based on the previous week’s MTTP?

Resources

View page source - Edit this page - please contribute.