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:
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.
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.
Categories: High-level capabilities that may be a standalone product at another company. e.g. Portfolio Management.
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.
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:
Infrastructure: confusing since there already is an infrastructure department, Geo and Distribution don't fit there well.
Platform: too generic.
Metal: closer to the bits and bytes, but confusing since it has nothing to do with bare-metal.
IO: other departments do IO as well.
Bookshelf: boring name?
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:
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.
Product Marketing: John
Manage - Jeremy
Reporting & Analytics
Value Stream Management Planned 2019
Financial Management Planned 2019
Audit Management Planned 2019
User management & authentication (incl. LDAP, signup, abuse)
Groups and Subgroups
GitLab.com (our hosted offering of GitLab)
Subscriptions (incl. license.gitlab.com and customers.gitlab.com)