For an understanding of what this team is going to be working on take a look at the product vision.
The Verify:Continuous Integration Group is focused on all the functionality with respect to Continuous Integration.
This team maps to Verify devops stage.
The following people are permanent members of the Verify:Continuous Integration group:
|Cheryl Li||Backend Engineering Manager, Verify:Continuous Integration|
|Matija Čupić||Backend Engineer, Verify:Continuous Integration|
|Fabio Pitino||Senior Backend Engineer, Verify:Continuous Integration|
|Marius Bobin||Backend Engineer, Verify:Continuous Integration|
|Furkan Ayhan||Senior Backend Engineer, Verify:Continuous Integration|
The following members of other functional teams are our stable counterparts:
|Grzegorz Bizon||Staff Backend Engineer, Verify:Continuous Integration|
|Dimitrie Hoekstra||Product Designer, Verify:Continuous Integration|
|Sarah Groff Hennigh-Palermo||Senior Frontend Engineer, Verify:Continuous Integration|
|Darby Frey||Senior Manager, Engineering, Verify|
|Payton Burdette||Frontend Engineer, Verify:Continuous Integration|
|Tiffany Rea||Software Engineer in Test, Verify:Continuous Integration|
|Thao Yeager||Senior Product Manager, Verify:Continuous Integration|
|Juan J. Ramirez||Senior Product Designer, Verify|
|Marcel Amirault||Technical Writer, Verify (Continuous Integration, Testing), Release (Progressive Delivery)|
|Suzanne Selhorn||Senior Technical Writer, Package, Release (Release Management), Verify (Runner)|
Like most GitLab backened teams we spend a lot of time working in Rails on the main GitLab CE app, but we also do a lot of work in Go which is the language that GitLab Runner is written in. Familiarity with Docker and Kubernetes is also useful on our team.
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
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.
Once the development phase begins, the team uses the CI Build board to communicate progress on issues. Note that the
Milestone filter is required to use this board.
Development moves through workflow states in the following order:
workflow::ready for development
Each member of the team can choose which issues to work on during a milestone by assigning the issue to themselves. When the milestone is well underway and we find ourselves looking for work, we default to working right to left on our CI Build board, by pulling issues in the right-most column. If there is an issue that a team member can help with on the board, they should do so instead of starting new work. This includes conducting code review on issues that the team member may not be assigned to, if they feel that they can add value and help move the issue along to completion.
Specifically, this means our work is prioritized in the following order:
workflow::in devif applicable
workflow::ready for developmentfor development column
The goal of this process is to reduce the amount of work in progress (WIP) at any given time. Reducing WIP forces us to "Start less, finish more", and it also reduces cycle time. Engineers should keep in mind that the DRI for a merge request is the author(s), to reflect the importance of teamwork without diluting the notion that having a DRI is encouraged by our values.
For issues being implemented in the current milestone, we use the Issue Health Status feature to designate the high level status of the issue. This issue health status is updated by the directly responsible individual (DRI) as soon as they recognize the state of the issue has changed.
The following are definitions of the health status options:
We track our technical debt using the following CI Technical Debt board, where we track issues in the planning phase. This board has 2 main sections:
workflow::planning breakdownwe find issues that are currently being groomed.
workflow::schedulingwe find issues that clearly defined and a weight has been assigned.
S4labels to classify the impact of the specific tech debt item. We use the list below as a guideline to grade the impact.
S1Blocking or Critical
Note that a multiple factors can exist at once. In that case use your judgment to either bump the impact score or lower it. For example:
S2bugs. Then choose
The CI team leverages a monthly async retrospective process as a way to celebrate success and look for ways to improve. The process for these retrospectives aligns with the automated retrospective process used by many teams at GitLab. The process is defined here: https://gitlab.com/gitlab-org/async-retrospectives#how-it-works.
A new retrospective issue is created on the 27th of each month, and remains open until the 26th of the following month. Team members are encouraged to add comments to that issue thoughout the month as things arise as a way to capture topics as they happen. The current issue can be found in https://gitlab.com/gl-retrospectives/verify/-/issues.
On the 16th of each month a summmary of the milestone will be added to the issue and the team will be notified to add any additional comments to the issue.
As comments are added to the issue, team members are encourage to upvote any comments they feel are important to callout, and to add any additional discussion points as comments to the original thread.
Around the 26th of the month, or after the discussions have wrapped up the backend engineering manager will summarize the retrospective and create issues for any follow up action items that need to be addressed. They will also redact any personal information, customer names, or any other notes the team would like to keep private. Once that has been completed the issue will be made non-confidential and closed.
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.
Daily standup updates are posted to
#g_ci. Feel free to ask us questions directly in this Slack channel and someone will likely get back to you within 24 hours (by the next business day). We will use following emojis to respond to the posted question accordingly:
:eyes:to indicate that one of us has seen it
:white_check_mark:to indicate that the question has been answered
Most spontaneous team communiation happens in issues and MRs. Our issues have a group label of
~"group::continuous integration". You can also tag a team member with
@mention in the issue if you have someone specific to ask.