The Verify Product Group wants to increase sharing, findability, and encourage bias for async communication. We will use this handbook page as forum for showcasing our team processes while also providing an opportunity to encourage a open discussion between team members on our processes for retrospective.
Slack: #s_verify
GitLab Project: Verify
Verify teams:
The purpose of this product group are described by the Verify stage direction. This is inclusive, though not limited to, the pipeline experience, creating or authoring .gitlab-ci.yml files, executing jobs in a pipeline, and various testing capabilties in CI/CD.
While generally the functions of Continuous Integration and Runners are interdependent (runners are the build agents that execute CI jobs), as Verify categories they represent distinct feature areas. However, it is sometimes difficult to discern which team or product manager is the DRI for a feature or capability that doesn't seem to fit neatly within the high-level categories and this section aims to clarify those boundaries.
At GitLab, using RADCIE to assign responsibilities means everyone is Consulted and Informed, but to highlight critical team members who must be consulted the table below specifies who explicitly.
The noted DRI still owns decision-making and is still responsible for notifying/consulting critical team members, however the 'Must be Consulted' designee(s) takes the guesswork out of who to involve when these team members may not be part of the core engineering team aligned to the DRI product manager.
| Category | Code Base | Description | PM DRI | EM DRI | Must be consulted |
|---|---|---|---|---|---|
| Runner Core | runner | Development of features for the core runner code base for use by self-managed customers on various compute platforms and architectures (runner binary, docker images) | Runner PM - Darren Eastman | Runner EM - Elliot Rushton | N/A |
| Runner Cloud | autoscaler | Development of capabilities for the GitLab SaaS build fleet, Shared Runners (Linux, Windows, macOS) | Runner PM - Darren Eastman | Runner EM - Elliot Rushton | Infrastructure Mgr. - David Smith |
| Runner Security, Enterprise Mgmt and UX | RAILS | Development of features for the configuration, use and administration of runners in the GitLab UI. | Runner PM - Darren Eastman | Runner EM - Elliot Rushton | Changes to the security or runner entity model requires input from lead engineers: Kamil Trzciński , Grzegorz Bizon, Stan Hu |
| Runners Configuration for GitLab SaaS | RAILS | Configuration changes for project and group runners by namespace. | Runner PM - Darren Eastman | Runner EM - Elliot Rushton | |
| Runner Cache Management | RAILS | Features and capabilities related to user configurable cache management in the GitLab UI. | Runner PM - Darren Eastman | Runner EM - Elliot Rushton | tbd |
| CI Pipeline Execution and Performance | RAILS | Features and capabilities for running or triggering a pipeline in the GitLab UI. | CI PM | CI EM - Cheryl Li | N/A |
| CI/CD Queueing GitLab SaaS and Self-Managed | RAILS | CI jobs queueing architecture. | Pipeline Execution PM | Lead engineers: Kamil Trzciński , Grzegorz Bizon, Stan Hu | |
| CI/CD Fair Scheduling GitLab SaaS | RAILS | CI jobs fair scheduling architecture and configuration. | Pipeline Execution PM | Lead engineers: Kamil Trzciński , Grzegorz Bizon, Stan Hu | |
| Compute units Configuration for GitLab SaaS | RAILS | Changes to compute units configuration for customers on GitLab SaaS. | Pipeline Execution PM | Lead engineers: Kamil Trzciński , Grzegorz Bizon, Stan Hu |
We work in a Kanban-style aligning with Milestones and GitLab's Product Development Flow.
We work across other teams often and are striving to get better at engaging with others. If you are interested in being a part of this dialogue - drop a line our #s_verify slack group!
We partner really closely with Product Marketing Management. In the Verify Stage, we have a stable counterpart assigned, as defined in the PMM Team Structure, which aligns to the CI Use Case.
We have four main processes:
We recently conducted our first joint stage-wide PMM and Product Positioning for FY22 1H, alongside a deck.
We recently participated in a discussion of building the bench for technical topics via cs-skill#116. These types of sessions would then be used in partnership with PMM to help build compelling stories for the Field.
Product Marketing Management can now plan ahead with the issue boards that indicate a look ahead for features we are thinking of delivering each quarter:
These are intended to help guide themes and present opportunities to build stories in the market and not commitments, otherwise, these would be scheduled for a milestone.
We sometimes ship feature specific blog posts such as Moving CI to Lovable…again or this expose on the Pipeline Editor. These are great opportunities to include PMM alongside the Release Post review and positioning.
We have a CS <> Product feedback loop for Customer Success (SA/CSM) and Product Managers to sync on product feedback from prospects and customers. On a monthly cadence, we meet to discuss problems to solve as captured in issues created in the cs-product-feedback project and consolidated on this issue board.
More details to come
We want to encourage and support our open source community as nuch as possible. We have two measures of success:
Our process for enabling merge requests from the community can be found on the Verify Team Page.
