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:
|Crystal Poole||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:
|Dimitrie Hoekstra||Product Designer, Verify (CI)|
|Cheryl L.||Engineering Manager, Verify:Testing|
|Zeff Morgan||Senior Software Engineer in Test, Verify:Testing|
|Tiffany Rea||Software Engineer in Test, Verify:Continuous Integration|
|James Heimbuck||Senior Product Manager, Verify, Verify:Testing|
|Thao Yeager||Senior Product Manager, Verify|
|Darren Eastman||Senior Product Manager, Verify:Runner|
|Juan J. Ramirez||Senior Product Designer, Verify|
|Marcel Amirault||Technical Writer, Verify|
|New Vacancy - Jason Yavorska (Interim)||Senior Product Manager, Verify:Continuous Integration|
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 Milestone Tracking 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:
workflow::ready for dev
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.
If you need to reach us urgently, try Slack first, #g_ci. Otherwise, @mention a team member in the issue you are working on.