Verify:CI Platform Group
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 Li
|
Senior Manager, Engineering, Verify |
 Senior Backend Engineer
|
Senior Backend Engineer, Verify:CI Platform |
Useful Links
Dashboards
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.
5982efc0)
