Delivery Team

1. You are here:
2. Engineering
3. Infrastructure
4. Team
5. Delivery Team

On this page

• Common Links
• Top-level Responsibilities
• Mission
• Vision
  • Short-term
  • Mid-term
  • Long-term
• Team
  • Team Members
    • Stable Counterparts
• Team training
• Performance indicators
• Team work processes
  • Workflow labels

Common Links

Top-level Responsibilities

• Acting as Release Managers for our monthly .com release process
• Migrate the company to a continuous delivery model (through automation)

Mission

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

Vision

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.

Short-term

• Automate release generation, removing most of manual work
• Automate deployment process, managing and limiting impact on production
• Simplify security releases
• Streamline the process of limiting feature impact in production environments
• Enable feature testing at production-environment scale
• Create detailed architecture blueprints and design for CD on GitLab.com
• Develop and track KPIs to measure the team's impact on GitLab product delivery

Mid-term

• Drive the implementation of infrastructure changes to prepare GitLab.com for CD
• Eliminate the need for feature-freeze blackouts during the development cycle
• Shorten build times to allow for faster release times

Long-term

• Drive necessary changes that will lead to Kuberentes-based infrastructure on GitLab.com
• Fully automated releases for self-managed users

Team

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

• Each team member is able to work on all team projects
• The team is able to reach a conclusion independently all the time, consensus most of the time
• Career development paths are clear
• Team creates a database of knowledge through documentation, training sessions and outreach

Team Members

The following people are members of the Delivery Team:

Stable Counterparts

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

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 (GitLab.com). 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 Periscope dashboard.

Team work processes

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:

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.