The following page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features or functionality remain at the sole discretion of GitLab Inc.
Managing an organization's deployments is a major challenge. Particularly in larger organizations, with the proliferation of services, technologies, dependencies on one side, and compliance and security requirements on the other side, many teams find themselves struggling to deploy frequently and consistently in a repeatable manner.
Platform teams want to help development teams become more efficient; so that they can meet compliance and security requirements and deploy to environments they can't (and probably shouldn't) update, without slowing down their ability to implement changes to their applications.
Help GitLab users to deploy in automated and standardized ways to any envrionment and target infrastructure.
GitLab distrupts the market with a fully declarative, scalable, modular, testable approach to deployment management that supports any major target infrastructure from bare metal servers to container orchestrators to edge devices and mobile app stores.
Declarative operations is to the devops pipeline what serverless is to infrastructure. It shifts the responsibility of operating the underlying systems to a service provider / controller, and enables the user to focus on their business instead.
The biggest difficulty with every automation tool is that it is code. As a result it requires developers to write it, a runtime environment to run it and a lot of investment into learning the tool chain. Compare this to the declarative nature of Kubernetes. With Kubernetes everyday developers realised that operations are complex, but operations were complex even before Kubernetes. Kubernetes, with its declarative, everything as data approach made this complexity approachable for every developer.
At the same time, Kubernetes made it clear that higher-level abstractions are required for developers without compromising the core flexibility of the container orchestrator.
We envision our solution to have several levels in terms of user value and complexity.
Today, we focus our efforts on the Gitlab Agent for Kubernetes. The agent provides great flexibility, but does not offer any out of the box, white-glove experiences for less experienced users. We want to add higher levels of abstractions on top of the agent.
The second level, what I call GitLab Delivery here, includes various integations, but experienced users can pick only parts of our recommended tooling and they can build their own processes around it. This level should integrate well with other GitLab stages, especially around Package, Release and Secrets management.
The third level, that is closes to the current Auto Deploy offering, provides a fully-managed solution for our users. It can approached from two different angles. First, from the software developers' point of view, it's a black box that should "just work" and provides a full, production ready delivery process. Second, from the platform engineers' point of view, it's a customized version of GitLab Delivery. That is it should be a framework to build custom delivery pipelines (not to be confused with CI pipelines) that result in white-glove solutions for the software engineer.
As we increase the value managed by GitLab, we need to increase the complexity owned by GitLab. At the agent level, we are responsible for the core cluster connection only. To best understand the agent, one should think of it as not providing any user-level features. It is responsible for maintaining a bi-directional communication channel between a cluster and GitLab. We add various features on top of this channel, like pull and push-based deployments, security scanning, direct access of cluster resources from the GitLab UI, etc. At this level, we try avoid 3rd party integrations as much as possible to minimize our maintenance costs and build an extremely reliable foundation for higher-level features.
At the GitLab Delivery level, we need to pick at least a few tools and integrated those into our offering. The set of tools likely includes an ingress, a secrets management solution, a certificate management solution, support for advanced deployment strategies and integrations with GitLab Observability.
On top of GitLab Delivery, Auto DevOps requires even more integrations. At this stage the vision is that the user provides us a Dockerfile and we return them a URL where they can check out their application. On top of the integrations mentioned under GitLab Delivery, we would likely want to add integrations with even more specific tools, like Knative and a Service Mesh. Finally, expanding the scope of Auto Deploy to other deployment targets, mobile for example, likely requires a totally new set of integrations.
We consider Deployment Management to be at the minimal level. We believe that the current CI/CD based approach, environments, releases are acceptable for many users, but are far from a distruptive solution.
As CI became mainstream, we believe that the next big market is around integrated and scalable deployment solutions. The total addressable market (TAMkt) for DevOps tools targeting the Release and Configure stages was $1.79B in 2020 and is expected to grow to $3.25B by 2024 (13.8% CAGR) (i). Continuous delivery alone, which does not include categories such as infrastructure as code, is estimated to have a market size of $1.62B in 2018 growing to $6B by 2026 (17.76% CAGR).
Deployment Management enables an integrated, programmable approach to serve this market, and provides opportunities for GitLab in the future.
The primary persona is the Platform Engineer. Their job is to support all the development teams with standardised and compliant pipelines.
The secondary personas are the Application Operator and the Compliance Manager. The Application Operator is responsible for deploying and operating the business applications, while the compliance manager assures that all the processes follow internal policies.
Deployments don't live in a vacuum, but are part of a companies delivery process. They are preceded and followed by CI jobs, are surrounded by security checks and guardrails, are integrated with monitoring and work in coordination with release management. We created a user story map to highlight and discuss these cross-stage and intra-group jobs and integration requirements.
This section establishes the pricing alignment scaffolding for this category based on GitLab's buyer-based tiering.
Managing deployments using existing CI/CD features, such as using include will continue to be free. For a large number of GitLab users, from individual developers to small companies, this is sufficient.
Orchestrating moderately complex deployments across a number of projects becomes hard to maintain and manage. Declarative management of multi-project deployment orchestration will fall under the Premium tier. These features enable development teams while keeping control within the platform team.
Features targeting a dedicated platform team fall under the Premium tier. While platform engineers are individual contributors, they do not contribute directly to the business. Their contribution is indirect, through increased developer productivity, security and reliability. Thus a platform teams assumes a non-IC decision maker who expects a level of standardization across several teams.
Helping organizations with a standards-based and compliant deployment pipeline is critically important that gets the attention of CIOs. Dashboards that summarize compliance and empower leaders with a birds-eye-view of their entire organization's change management solves a fundamental problem for GitLab's largest customers.
Security guardrails and policy attestation support and reporting fall under this category.
Today, GitLab CI/CD is used by many Gitlab customers to manage their deployments. GitLab CI/CD is a mixture of imperative and declarative code that is hard to test and its YAML based syntax does not offer much possibility for scalable, modular setup. As deployments are complex processes where all the previous work and requirements need to converge having strong foundations is crucial.
As GitLab already provides support to deploy into non-production and production environments, we updated the GitLab Documentation to reflect this by moving existing content under "Use GitLab / Release Your Application" and renaming "Release Your Application" to "Deploy and Release Your Application"
This section shares our current approach and plans towards a Deployment management project built-into GitLab. This direction is currently being researched and architected. It will very likely change. Your feedback is more than welcome!
A core building block of a Deployment management is a GitLab project to store the declarative deployment definitions in a structure following GitLab-defined conventions and the GitLab agent for Kubernetes, to consume the content stored in a GitLab Deployment management project. A Deployment management project is supported by GitLab as long as it follows the GitLab conventions.
A note to help understand the management project: This approach we imagine is similar to various frontend tools, like "Create React App", "Expo" (React Native). These tools provide a simplified experience out of the box for 80% of the use cases. If the user needs more flexibility, they can eject. Thus, the user owns their project, but a lot of complexity remains hidden from them to support them focusing on their business problem. This is aligned with the convention over configuration product principle.
The Deployment management project should describe:
The Deployment management project might include:
We want to work closely with the Release stage in shipping the Deployment management project. The Release stage is responsible for visualising Environments and related deployment instances.
This section shares our current approach and plans towards simplifying the Delivery experience for our users . This direction is currently being researched and architected. It will very likely change. Your feedback is more than welcome!
The GitLab Delivery framework is an opinionated selection of tools to support platform teams in providing white-glove delivery experiences to software developers.
| Ease of use | Complexity |
|---|---|
|
|
The more user friendly we make a solution, the more complexity we become responsible for. Increasing complexity means increasing maintenance costs and higher customer value.
The agent for Kubernetes is the core building block of GitLab Delivery. It is reliable, production ready tool for declarative deployment management of Kubernetes clusters built around GitOps principles. GitLab Delivery extends our product offering on top of the agent for Kubernetes.
The GitLab Delivery layer wants to offer a customizable selection of shared cluster tools from ingress to observability that we have integrated across GitLab. At the GitLab Delivery level, we need to pick at least a few tools and integrated those into our offering. The set of tools likely includes an ingress, a secrets management solution, a certificate management solution, support for advanced deployment strategies and integrations with GitLab Observability. This level should integrate well with other GitLab stages, especially around Package, Release and Secrets management.
GitLab Delivery will be integrated with the Deployment management project. The two working together should support
Nota bene: What we call GitLab Delivery here falls under the larger GitLab Delivery direction. The GitLab Delivery framework - as the name suggests - is a central component of the overall direction, but is not the direction itself. The scope of the Delivery direction relies heavily on the work on the Release stage to support release managers. The work on the Delivery framework needs to be aligned with the Release stage strategy as they supplement each other. Similarly, the Delivery framework work together with the Continuous Verifications category direction, that is part of the bigger Delivery direction.
We reviewed (internal) Keptn, Argo and Harness in early 2022.