Verify:CI Platform Group

The GitLab Verify:CI Platform Group Handbook page

Vision

Our team is responsible for the following categories:

Mission

  • Ensure that GitLab Continuous Integration is scalable, performant and reliable, by improving the resiliency of our product, as well as future proofing the CI platform as we grow.
  • Support database and infrastructure initiatives that our CI Platform requires to remain operational.

Team Members

The following people are permanent members of the Verify:CI Platform group:

Name Role
Cheryl LiCheryl Li Senior Manager, Engineering, Verify
Senior Backend EngineerSenior Backend Engineer Senior Backend Engineer, Verify:CI Platform
Leaminn MaLeaminn Ma Senior Backend Engineer, Verify:CI Platform
Marius BobinMarius Bobin Senior Backend Engineer, Verify:CI Platform
Madhusudan VaishnaoMadhusudan Vaishnao Backend Engineer, Verify:CI Platform
Tianwen ChenTianwen Chen Senior Backend Engineer, Verify:CI Platform

Dashboards

See internal handbook page

How we work

Milestone Planning Process

Given the nature of CI Platform’s work, we do not have a stable Product counterpart. However, we use planning issues as a place to visually centralize the work we are committing to in a milestone.

Engineering Manager responsibilities:

  • Reviews carryover work from previous milestone
  • Evaluates realistic delivery capacity

Team member responsibilities:

  • Selects next set of issues from their projects to meet roadmap timelines
  • Surfaces risks and timeline impacts early

Non-roadmap items that may be planned include:

  • Security issues (to meet SLAs)
  • Customer bugs and requests for help (RFH)
  • Minor reliability/performance fixes

Instrumentation is a key requirement for all features to measure impact and effectiveness. This helps us validate adoption and make data-driven decisions.

Issue Management

Workflow

We use the issue status field to note the current state of the issue.

  • New/Start: issues that have just been created
  • Problem Validation: applies to features and bugs we want to work on but have not a clear proposal or implementation details (need refinement)
  • Blocked: issues that require other issues to be completed first
  • Ready for development: issues that have a clear implementation and have weight set
  • In dev: work has started and is currently in progress
  • In review: all related MRs are now in the review process
  • Verification: all MRs have been merged and are waiting to be verified in pre/staging/production
  • Complete: all has been verified, the issue can be closed

Issue Weighting Guidelines

Weight Description Confidence Level
1: Trivial Well understood, no investigation needed, exact solution known ≥90%
2: Small Well understood, minimal investigation needed, few surprises expected ≥75%
3: Medium Well understood but requires investigation, some surprises expected ≥60%
4: Large Basic understanding, requires further investigation, can potentially be broken down as the work progresses ≥50%
Larger Should be broken down into smaller issues ≥40%

An issue with weight 1 should take no more than 2 days to complete.

Async Status Updates

The purpose of async updates is to communicate progress and allow others to prepare for upcoming work as necessary. In an all-remote culture, we keep the updates asynchronous and put them directly in the issues.

The async update communicates the progress and confidence using an issue comment and the milestone health status. Add a comment in your issue with the title Async Update once per week, or when something notable happens with regard to the issue. It’s preferable to update the issue rather than the related merge requests.

The async update comment should include:

## Async Status Update yyyy-mm-dd

- **Progress & Status**: _What progress have you made? What's the current state?_
- **Next Steps**: _What are your planned next actions?_
- **Blockers**: _Are you blocked or need assistance with this?_
- **How confident are you that this will make it to the current milestone?**
  - [ ] Not confident
  - [ ] Slightly confident
  - [ ] Very confident

/health_status <on_track|needs_attention|at_risk>
/cc @jaime

Async Collaboration

Every other day

We use geekbot integrated with Slack for our every-other-day async standup to make our current work and upcoming work more visible.

Weekly

Given the distributed nature of our team members, our “team meetings” consist of collaborating async through a Google Doc Agenda (internal). Slackbot will remind the team weekly to review the agenda and encourage us to collaborate through the agenda.

Monthly

We use a GitLab issue in the (internal) async retrospectives project for our monthly retrospective. The purpose of the monthly retrospective issue is to collaborate async and reflect on how the milestone went, in terms of:

  • what went well
  • what didn’t go so well
  • what we can do improve upon
  • what praise we have for one another.

Instead of waiting until the end of the milestone to add items to the retrospective issue, we encourage team members to add comments throughout the month. The issue’s due dates and Slackbot reminders serve as reminders to contribute feedback to our issue prior to closing.

Labels

Category Labels

The CI Scaling group supports the feature categories described below:

Label
Category:Continuous Integration (CI) Scaling Issues MRs Direction Documentation - TBD

Developer Onboarding

Refer to the Developer Onboarding in Verify section.