---
layout: handbook-page-toc
title: "Verify:Continuous Integration Group"
---

## On this page
{:.no_toc .hidden-md .hidden-lg}

- TOC
{:toc .hidden-md .hidden-lg}

## Vision

For an understanding of what this team is going to be working on take a look at [the product
vision](/direction/verify/).

## Mission

The Verify:Continuous Integration Group is focused on all the functionality with respect to
Continuous Integration.

This team maps to [Verify](/handbook/product/categories/#verify-stage) devops stage.

## Team Members

The following people are permanent members of the Verify:Continuous Integration group:

<%= shared_team_members(role_regexps: [/Verify(?!:)/, /Verify:Continuous Integration/]) %>

## Stable Counterparts

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

<%= stable_counterparts(role_regexp: /[,&] Verify/, direct_manager_role: 'Engineering Manager, Verify:Continuous Integration', other_manager_roles: ['Frontend Engineering Manager, Verify', 'Engineering Manager, Verify:Testing', 'Engineering Manager, Verify:Runner']) %>

## Technologies

Like most GitLab backened teams we spend a lot of time working in Rails on the main [GitLab CE app](https://gitlab.com/gitlab-org/gitlab-ce), but we also do a lot of work in Go which is the language that [GitLab Runner](https://gitlab.com/gitlab-org/gitlab-runner) is written in. Familiarity with Docker and Kubernetes is also useful on our team.

## Common Links

 * [Issue Tracker](https://gitlab.com/groups/gitlab-org/-/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=Verify)
 * [Slack Channel](https://gitlab.slack.com/archives/g_ci)
 * [Roadmap]()

## How to work with us

### Planning

**Weekly** the team meets to discuss issues with the `workflow::planning breakdown` label. Each engineer generally grooms one issue per week and prepares ahead of time to present their findings to the team.  This discussion is focused on how we plan to address the issues which are prioritized for the upcoming milestone.  Issues may need to be broken down if they are too large for a milestone, or further research may be necessary, but each member of the team should be familiar enough with the issue to begin working on it.  The goal of this meeting is to ensure that issues are well documented and appropriately weighted.  

Once the issue is groomed and weighted engineers move it into `workflow::scheduling` column.  

**Weekly** the Product Manager and Engineering Manager discuss which issues are highest priority from the list of `workflow::scheduling` issues.  The Product Manager then applies the `VerifyP1` label to the top issues and the Engineering Manager applies the `workflow::ready for development` label when the team has capacity to begin working on them.  In addition to Product prioritized issues, the team will select tech debt issues that we plan to deliver during the milestone.


### Workflow

Once the development phase begins the team uses the [Milestone Tracking](https://gitlab.com/groups/gitlab-org/-/boards/364216?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=group%3A%3Acontinuous%20integration&label_name[]=VerifyP1) board to communicate progress on issues. 

Each member of the team can choose which issues to work on during a milestone by assigning the issue to themselves.  As a team, we meet weekly to review the board, montior our throughput and ensure that we don't have too many issues in progress.

Development moves through workflow states in the following order: 

1. `workflow::ready for dev` 
1. `workflow::in dev` 
1. `workflow::blocked` (as necessary)
1. `workflow::in review` 
1. `workflow::validation` 
1. `workflow::staging`
1. `workflow::canary`
1. `workflow::production`
1. `Closed`

### Team Communication

The CI team is globally distributed and separated by many timezones.  This presents some challenges in how we communicate since our work days only overlap by a couple hours.  We have decided as a team to embrace asynchronous communication because scheduling meetings is difficult to coordinate.  We meet as a team one day per week, on Wednesdays for a quick team meeting and 1-on-1s.

- Written communication is essential.  Daily standup updates are in Slack and most spontaneous team communiation happens in issues and MRs.
- We are pro-active about asking questions in advance with the understanding that the turnaround on receiving an answer is usually a full working day.
- Our engineering plan and issue boards need to be updated regularly to communicate what stage our work is in.
- Any meetings that we hold need a preset agenda and are recorded for folks who are unable to attend.
- Having a positive work/life balance, despite these challenges, must be a high priority and handled intentionally so no one is routinely starting early or staying late to attend meetings.

If you need to reach us urgently, try Slack first, #g_ci.  Otherwise, @mention a team member in the issue you are working on.