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

Delivery Team

Workflow Team workflow @gitlab-org/delivery
Issue Trackers Delivery
Slack Channels #g_delivery / @delivery-team
Delivery Handbook Team training

Top-level Responsibilities


The Delivery Team enables GitLab Engineering to deliver features in a safe, scalable and efficient fashion to both and self-managed customers. The team ensures that GitLab's monthly, security, and patch releases are deployed to and publicly released in a timely fashion.


By its own nature, the Delivery team is a backstage, non-user feature facing team whose product and output has a direct impact on Infrastructure's primary goals of availability, reliability, performance, and scalability of all of GitLab's user-facing services as well as self-managed customers. The team creates the workflows, frameworks, architecture and automation for Engineering teams to see their work reach production effectively and efficiently.

The Delivery team is focused on our CI/CD blueprint by driving the necessary changes in our software development processes and workflows, as well as infrastructure changes, to embrace the benefits of CI/CD.





Each member of the Delivery team is part of this vision:

Team Members

The following people are members of the Delivery Team:

Person Role
New Vacancy - Marin Jankovski (Interim) Engineering Manager, Delivery
Robert Speicher Senior Backend Engineer, Delivery
Yorick Peterse Staff Backend Engineer, Delivery
John 'Jarv' Jarvis Staff Site Reliability Engineer, Delivery
Alessio Caiazza Senior Backend Engineer, Infrastructure
Mayra Cabrera Senior Backend Engineer, Infrastructure
John T Skarbek Senior Site Reliability Engineer, Delivery

The following members of other functional teams are our stable counterparts:

Person Role
Marin Jankovski Senior Engineering Manager, Infrastructure, Delivery & Scalability
André Luís Frontend Engineering Manager, Create:Source Code, Delivery & Scalability

Team training

Every Delivery team member is responsible for creating a training session for the rest of the team. See the page on team training for details.

Performance indicators

Delivery team contributes to Engineering function performance indicators through Infrastructure department performance indicators. Team's main performance indicator is Mean Time To Production (MTTP), which serves to show how quickly a change introduced through a Merge Request is reaching production environment ( At the moment of writing, the target for this PI is defined in this key result epic.

MTTP is further broken down into charts and tables at the Delivery Team Performance Indicators Sisense dashboard.

Team work processes

The Delivery team work is tracked through number of epics, and issues.

Two important epics related to the team mission are:

  1. on Kubernetes
  2. Release Velocity

Workflow labels

The Delivery team leverages scoped workflow labels to track different stages of work. They show the progression of work for each issue and allow us to remove blockers or change focus more easily. These labels are used in projects that are projected to take some time to complete and usually combined with other project or service labels.

The standard progression of workflow is described below:

sequenceDiagram workflow|Triage ->> workflow|Ready: 1 Note right of workflow|Triage: Problem has been
scoped, discussed and issue is
ready to implement. workflow|Ready ->> workflow|In Progress: 2 Note right of workflow|Ready: Issue is assigned and
work has started. workflow|In Progress ->> workflow|Done: MR is merged and deployed to production Note right of workflow|In Progress: Issue is updated with
rollout details
, and workflow|Done label
is applied so the issue
can be closed.

There are three other workflow labels of importance omitted from the diagram above:

  1. workflow::Cancelled:
    • Work in the issue is being abandoned due to external factors or decision to not resolve the issue. After applying this label, issue will be closed.
  2. workflow::Stalled
    • Work is not abandoned but other work has higher priority. After applying this label, team Engineering Manager is mentioned in the issue to either change the priority or find more help.
  3. workflow::Blocked
    • Work is blocked due external dependencies or other external factors. After applying this label, issue will be regularly triaged by the team until the label can be removed.

Label Workflow::Done is applied to signify completion of work, but its sole purpose is to ensure that issues are closed when the work is completed, ensuring issue hygiene.

Release runbooks

Runbooks containing information on various scenarios that the release manager from the Delivery team needs to know are available at the release/docs/runbooks repository.