Product categories

On this page

Manage Plan Create Verify Package Release Configure Monitor Secure

Interfaces

We want intuitive interfaces both within the company and with the wider community. This makes it more efficient for everyone to contribute or to get a question answered. Therefore, the following interfaces are based on the product categories defined on this page:

Hierarchy

The categories form a hierarchy:

  1. Departments: Dev and Ops. Dev and Ops map to departments in our organization structure. At GitLab the Dev and Ops split is different then the infinity loop suggests because our CI/CD functionality is one codebase, so from verify on we consider it Ops so that the codebase falls under one department. The stages that are the difference between the value stages and the team stages are part of the Dev department.
  2. Stages: Stages start with the 7 loop stages, then add Manage and Secure to give the 9 (DevOps) value stages, and then add Distribution, Geo, Gitaly & Gitter to get the 12 team stages. Values stages are what we all talk about in our marketing. Each of the team stages has a dedicated engineering team, product manager. Within shared functions like quality and product management individuals are paired to one or more stages so that there are stable counterparts.
  3. Categories: High-level capabilities that may be a standalone product at another company. e.g. Portfolio Management. There are a maximum of 8 high-level capabilities per stage to ensure we can display this on our website and pitch deck.
  4. Features: Small, discrete functionalities. e.g. Issue weights. Some common features are listed within parentheses to facilitate finding responsible PMs by keyword. Features are maintained in features.yml.

Every category listed on this page must have a link, determined by what exists in the following hierarchy:

Marketing product page > docs page > epic > label query > issue

E.g if there's no marketing page, link to the docs. If there's no docs, link to the Epic. Etc.

Solutions can consist of multiple categories as defined on this page, but there are also other ones, for example industry verticals.

Capabilities can refer to stages, categories, features, but not solutions.

Adding more layers to the hierarchy would give it more fidelity but would hurt usability in the following ways:

  1. Harder to keep the interfaces up to date.
  2. Harder to automatically update things.
  3. Harder to train and test people.
  4. Harder to display more levels.
  5. Harder to reason, falsify, and talk about it.
  6. Harder to define what level something should be in.
  7. Harder to keep this page up to date.

Changes

The impact of changes to stages is felt across the company. Merge requests with changes to stages and significant changes to categories need to be approved by:

  1. Head of Product
  2. VP of Product
  3. VP of Engineering
  4. CEO

DevOps Stages

DevOps Loop

Dev department

Dev leadership

Dev stages

  1. Manage | PM: Jeremy Watson | PMM: John Jeremiah | EM: Liam McAndrew | FEM: Tim Z (Interim) | CM: Suri Patel | TW: Evan Read
  2. Plan | PM: Victor Wu | PMM: John Jeremiah | EM: Sean McGivern | FEM: André Luís | CM: Suri Patel | TW: Mike Lewis
  3. Create | PM: James Ramsay | PMM: John Jeremiah | EM: Douwe Maan | FEM: André Luís | CM: Suri Patel | TW: Marcia Ramos
  1. Distribution | PM: Joshua Lambert | PMM: William Chia | EM: Marin Jankovski | FEM: Clement Ho | TW: Axil
  2. Gitaly and Gitter | PM: James Ramsay | PMM: John Jeremiah | EM: Tommy (interim) | FEM: Tim Z (Interim) | TW: Axil
  3. Geo | PM: Andreas Kämmerle | PMM: John Jeremiah | EM: Rachel Nienaber | FEM: André Luís (Interim) | TW: Evan Read

Ops department

Ops leadership

Ops stages

  1. Verify | PM: Jason Lenny (Interim) | PMM: William Chia | EM: Elliot Rushton | FEM: Tim Z (Interim) | CM: Aricka Flowers | TW: Evan Read
    • Internal Customer: Quality Department
  2. Package | PM: Joshua Lambert | PMM: William Chia | EM: Marin Jankovski (Interim) | FEM: Clement Ho | CM: Aricka Flowers | TW: Axil
    • Internal Customer: Distribution Team
  3. Release | PM: Jason Lenny | PMM: William Chia | EM: Elliot Rushton (Interim) | FEM: Tim Z (Interim) | CM: Aricka Flowers | TW: Marcia Ramos
    • Internal Customer: Release Managers
  4. Configure | PM: Daniel Gruesso | PMM: William Chia | EM: Dylan Griffith | FEM: Tim Z (Interim) | CM: Aricka Flowers | TW: Evan Read
    • Internal Customers: Site Availability Engineering, Site Reliability Engineering
  5. Monitor | PM: Joshua Lambert | PMM: William Chia | EM: Seth Engelhard | FEM: Clement Ho | CM: Aricka Flowers | TW: Axil
    • Internal Customer: Infrastructure Department
  6. Secure | PM: Fabio Busatto | PMM: Cindy Blake | EM: Philippe Lafoucrière | FEM: Tim Z (Interim) | CM: Erica Lindberg | TW: Axil
    • Internal Customer: Security Department

Maturity

Not all categories are at the same level of maturity. Some are just minimal and some are lovable. See the category maturity page to see where each category stands.

Solutions

GitLab also does the things below that are composed of multiple categories.

  1. Software Composition Analysis (SCA) = Dependency Scanning + License Management
  2. Interactive Application Security Testing (IAST) = Dynamic application security testing (DAST) + Runtime Application Self-Protection (RASP)
  3. Application Performance Monitoring (APM) = Metrics + Tracing
  4. Project management = Issue trackers + Issue boards
  5. Continuous Integration (CI) = Unit Testing + Integration Testing + System Testing + Acceptance Testing (UAT) + Usability Testing + Compatibility Testing

Other functionality

This list of other functionality so you can easily find the team that owns it. Maybe we should make our features easier to search to replace the section below.

Other functionality in manage

Other functionality in plan