Gitlab hero border pattern left svg Gitlab hero border pattern right svg

GitLab Engineering Workflows

Resources

Epics:

Blueprints:

Designs:

Introduction

GitLab (the company) has two equally important goals:

Both goals have the same requirement of exposing new features, resolving bugs and providing timely security fixes.

The difference between the two comes in timing, namely GitLab.com receives the latest code before the release is publicised.

More details about GitLab.com and releases can be found in the CI/CD blueprint.

Terminology

Idea/Problem Statement

To get GitLab.com to a CI/CD deployment model as mentioned in the [CICD blueprint], there are a number of items that need to happen first to ensure the stability of GitLab.com as a service and preserve the public release for self-managed users.

This requires a shift in processes that the engineering teams are using, and can roughly be divided into the following:

Delivery team has been tasked with driving this effort, with the help from the rest of the engineering.

Process overviews

All of the individually listed processes are equally important. The required work to make a change differs based on the amount of people affected by it.

It is simple to get lost in the amount of details each of these processes brings, so the aim of this document is to target the processes with the least amount of work/highest impact first, before addressing the rest.

This is the reason why we will start with the current release process.

Release process design