Product categories


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:


The categories form a hierarchy:

  1. Department: Dev, Non-DevOps, and Ops. These map to departments in our organization structure with the caveat that currently the Dev and Non-DevOps leadership is combined in one department called Dev.
  2. Stages: Stages start with the 7 stages of the infinity loop, then add Manage and Secure to give the 9 DevOps stages, and then add the non-devops stages. Stages map directly to engineering teams and product managers so they make sense across Engineering, Product, and Product Marketing, and ultimately to the end prospect or customer.
  3. Categories: High-level capabilities that may be a standalone product at another company. e.g. Portfolio Management.
  4. Capabilities: An optional group of functionality that is made up of smaller discrete features. e.g. Epics. Capabilities are listed as the second tier of bullets below. We have feature categories but it is incomplete and not used everywhere.
  5. 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.


The Non-DevOps department name is not ideal. It is negative and might create the confusion that that department is not practicing DevOps themselves. We're thinking about other names:

  1. Infrastructure: confusing since there already is an infrastructure department, Geo and Distribution don't fit there well.
  2. Platform: too generic.
  3. Metal: closer to the bits and bytes, but confusing since it has nothing to do with bare-metal.
  4. IO: other departments do IO as well.
  5. Bookshelf: boring name?
  6. Atlas: overused
  7. Persistent: since there is a data gravity to most teams in here


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 stages


Organizations manage their operation to optimize their value to their users, customers, and stakeholders by continuously improving their products and services. As such, the business needs insight and data into their effectiveness and they need specific process, cycle, and financial metrics to improve their performance. The process of managing the business is always on.


Planning is focused on the prioritization of ideas, allocation of resources ($, human and technology), scheduling projects, tracking status, coordination across the business, and resolving conflicts between efforts. Typically planning includes practices such as: Collaboration, Issue Management, Project Management, Program Management, Portfolio Management, Resource Management, Requirements Management, and Financial Management (as it relates to projects).


Collaboratively design, develop, and implement capabilities in the application to meet business goals and objectives. Teams establish processes and mechanisms to track and review multiple versions of their code as they iterate through frequent improvements.


Verification ensures the quality of the software by automatically and consistently building, integrating, and testing code changes; minimizing conflicts and rework. Verification includes functional testing (unit, integration, and acceptance) and non-functional testing (performance, security, and usability). Ideally, verification tests are fully automated and provide rapid feedback so that only high quality changes are accepted.


Assemble and manage the different versions of components, libraries, and other elements that are required to run the application, so that the application can be deployed consistently and repeatedly to different execution environments.


Deliver and deploy the application in the target environment. When 'releasing' the application, the environment is typically production. Often teams will use strategies to gradually release changes into their environment, such as Canary deployments or Blue/Green deployments.


Make application-specific settings that enable the application to be fully functional and optimized in a specific environment. Ideally configuration settings and details are centrally managed (like code) and are applied automatically to reduce the potential for human error.


Rapid and reliable feedback from production is critical in order to embrace continuous improvement. This feedback must be collected from both external and internal vantage points to be effective. Applications must be designed and built to allow for telemetry and utilization data to enable the business and delivery team to iterate and continuously improve the application.


Ensuring the application is secure and trusted is an activity that spans the entire development lifecycle from planning to monitoring. Requirements and policies should set security expectations, design and development incorporate secure practices, every change should be tested for security (SAST,DAST), libraries and dependencies tracked and managed, containers and infrastructure secured, and the entire lifecycle monitored to ensure compliance. Delivering secure applications depends on every stage in the life cycle.

Dev and Ops split

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.

Dev department

Dev leadership

Dev stages

  1. Manage - Jeremy
    • Reporting & Analytics
      • Cycle analytics
      • DevOps Score
    • Value Stream Management Planned 2019
    • Financial Management Planned 2019
    • Audit Management Planned 2019
    • Administration
      • User management & authentication (incl. LDAP, signup, abuse)
      • Groups and Subgroups
      • Navigation
      • Audit log
      • (our hosted offering of GitLab)
      • Subscriptions (incl. and
      • Internationalization
      • Projects (Project creation, project templates, project import/export, importers)
      • Admin Area
  2. Plan - Victor
    • Project management
      • Issue and merge request trackers (assignees, milestones, time tracking, due dates, labels, issue weights, quick actions, email notifications, todos, search, Elasticsearch integration, Jira and other third-party issue management integration)
      • Issue page and merge request page commenting and discussions
      • Issue boards
    • Program Management Planned 2019
    • Portfolio Management New in 2018
      • Epics
      • Roadmaps
    • Requirements Management Planned 2019
    • Service desk
    • Chat integration (Mattermost, Slack)
    • Markdown
    • Version check (incl., Usage ping) - [Victor]
  3. Create - James
    • Source code management
      • Version control (Git repository, Commits, file locking, LFS, protected branches, mirroring, housekeeping (e.g. `git gc`), hooks)
      • Gitaly
    • Code Review (merge requests, diffs, approvals)
    • Web IDE New in 2018
    • Wiki
    • Snippets

Ops department

Ops leadership

Ops stages

  1. Verify - Jason (Interim)
    • Continuous Integration (CI)
      • Unit Testing
      • Integration Testing
      • System Testing Planned 2019
      • Acceptance Testing
      • Performance Testing New in 2018
      • Usability Testing Planned 2019
      • Compatibility Testing Planned 2019
      • GitLab Runner
  2. Package - Josh
    • Container Registry
    • Binary Repository Planned 2018
  3. Release - Jason
    • Continuous Delivery (CD)
    • Review apps
    • Release Automation
    • Feature Management Planned 2018
      • Feature flags
    • Pages
  4. Configure - Daniel
    • Application Control Panel New in 2018
      • Auto DevOps
    • Infrastructure Configuration New in 2018
    • Operations Planned 2018
      • ChatOps New in 2018
    • Serverless Planned 2019
  5. Monitor - Josh
    • Application Performance Monitoring (APM)
      • Metrics
      • Tracing Planned 2018
    • Infrastructure Monitoring New in 2018
      • Cluster Monitoring New in 2018
    • Production Monitoring Planned 2018
    • Error Tracking Planned 2018
    • Logging Planned 2018
    • Incident Management Planned 2019
  6. Secure - Fabio
    • Security Testing
      • Static Application Security Testing (SAST) New in 2018
      • Dynamic Application Security Testing (DAST) New in 2018
      • Dependency Scanning New in 2018
      • Container Scanning New in 2018
      • Runtime Application Self-Protection (RASP) Planned 2018
    • License Management New in 2018

Non-DevOps department

Non-DevOps leadership

Exactly the same as the Dev leadership.

Non-DevOps stages

  1. Distribution - Josh
    • Omnibus
    • Cloud Native Installation Planned 2018
  2. Gitaly - James
  3. Geo - Andreas
  4. Production - Job

Composed categories

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)