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:

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
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: Deployment and Release process overview

Diagram source

Engineer creates features or bug fixes. Changes reviewed by Maintainers
Validated changes merged into the default branch
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
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
The auto-deploy package is deployed to GitLab.com. For more details see the deployment process
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
The release candidate is deployed to a test environment and automated QA tests execute
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:

On GitLab issues and epics by using @gitlab-org/release/managers handle
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 - MTTP Weekly - Deployment blockers - Deployment SLO - GitLab: deployment frequency - GitLab: lead time

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

Resources

Description	Location
Release documentation	Link
Release related tasks issue tracker	Link
Delivery team issue tracker	Link
Release manager schedule	Link
Deployment process	Link
Release process	Link
Maintenance Policy	Link