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.
The delivery direction covers the deployment and release functionality of GitLab. Users of both cloud-native and legacy infrastructures should benefit from the delivery direction. This direction brings them high-level automations that just work out of the box following GitLab conventions and low-level integration points that enable users to build their own flavor of deployment and release functionality. Legacy infrastructures are served through GitLab CI/CD, while cloud-native infrastructures, especially Kubernetes, are supported with the agent for Kubernetes.
Delivery is when you promote a coded, integrated, and built software application to a production environment. Once you deliver an application, users derive value from it. Delivery is composed of two parts, deployment and release. Deployment covers the processes and actions needed to deploy a new version of the software to a target infrastructure. This includes both production and non-production infrastructures. Release includes the processes and actions needed to make a deployed application available to the users. As delivery starts with a tested artifact, like a container, it might take several deployments into various environments and a final release or set of releases for the container to serve users.
Delivery is difficult, however, with the competition in the market today, increased velocity and stability are a necessity. Delivery is where development and operations meet and the focus turns to operations. Delivery is a team sport. It requires empowered developers and it requires guardrails set by operators. In overcoming these hurdles, teams must:
Ephemeral or declarative infrastructure blurs the line between infrastructure configuration, software development and software delivery. At GitLab, the Delivery direction belongs to the Ops section, and it is primarily the responsibility of the Environments group. At the same time, we acknowledge that Delivery does not exist in a vacuum. As already mentioned, Delivery is where the focus shifts from development to operations. As a result, the Delivery direction starts with a secure packaged artifact and should support and integrate well with Day-2 operations. These are covered by the Secure, Package and Monitor stages of GitLab, respectively.
This direction is about delivery, in general. As a result, we speak about delivery overarching deployment and release functionalities. There are nevertheless two industry terms, "continuous delivery" and "continuous deployment" that might confuse the reader of this page. To remove this confusion, we provide here Martin Fowler's definition of these related terms:
Continuous Delivery is a software development discipline where you build software in such a way that the software can be released to production at any time. … Continuous Deployment means that every change goes through the pipeline and automatically gets put into production, resulting in many production deployments every day. … Continuous Integration usually refers to integrating, building, and testing code within the development environment. Continuous Delivery builds on this, dealing with the final stages required for production deployment.
The Delivery direction includes both Continuous Delivery and Continuous Deployment, while Continuous Integration is covered by the Verify stage.
GitLab's Delivery vision is to enable your organization to be an elite performer in DevOps by providing your tools and frameworks to automatically turn the hardest part of DevOps - software delivery - easy, flexible and secure.
We will accomplish this by
We created a glossary to discuss related terms in a consistent way.
The total addressable market (TAMkt) for DevOps tools targeting the Delivery scope was $1.79B in 2020 and is expected to grow to $3.25B by 2024 (13.8% CAGR) (i). This analysis is considered conservative as it focuses only on developers and doesn't include other users. External market sizing shows even more potential. For example, 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). This, like the Ops market in general, is a deep value pool and represents a significant portion of GitLab's expanding addressable market.
The delivery tooling market is evolving and expanding. There are now many more options than just adding a deployment job to your CI/CD pipeline. Release Orchestration, advanced releases, GitOps, infrastructure provisioning, platform as a service, progressive delivery, and feature flags are all methodologies that help teams deliver software more easily, frequently, and confidently. Completeness of feature sets from vendors is becoming increasingly important as teams want the benefits from all worlds; traditional, table stakes deployment features alongside modern, differentiating features.
To increase deployment frequency and be competitive in the market, enterprises have turned to centralized cloud teams or cloud center of excellence that are responsible for helping development teams be more efficient and productive. These teams have centralized buying power for DevOps and delivery tools. They may also have organizational support to build a DIY DevOps platform. For cloud-native DIY platforms, we've found (through customer interviews) that open-source point deployment solutions (such as Flux or ArgoCD) are the primary options because of their focus on cloud-native principles and early adoption of pull-based deployment. These tools often come with auxiliary tooling for release management, like Flagger and Argo Rollouts Otherwise, enterprises, even existing GitLab customers, sometimes buy commercial tools for deployment, such as Octopus, Harness, and CloudBees electric flow.
We want to be good cloud-native citizens, build on top of and contribute back into open source tools. We believe in the power of the open source community and GitLab's everyone can contribute ethos.
We understand that Infrastructure as Code and cluster management at scale are complex, and best of breed technologies and much customization is required to fulfill advanced workflows. We want to support such advanced use cases. At the same time, we believe that many new users will become advanced users, and we can support them as well by providing production ready, turn-key solutions that incorporate the best practices followed by experts.
At GitLab we build a single application for the whole Dev(Sec)Ops pipeline. Our solutions should integrate deeply with and should support other GitLab features. We are paying special attention to security and collaboration oriented features.
While we want to provide supporting products for every company size, we expect enterprise users to have special needs that our integrated approach can serve well. Focusing on their use cases we can reduce their costs and enable faster go to market
In Delivery, our primary persona is Priyanka (Platform Engineer). They are responsible for setting up the systems that development teams use to develop, test, ship, and operate their applications. They - likely - work at an enterprise where there is a mix of delivery targets from VMs to Kubernetes and bare metal to cloud infrastructure. They also face the challenges of ever-increasing complexity; as more contributors, more services, more infrastructure, more databases, and a mix of technologies are added to their applications. They are looking for ways to create a system to manage the complexity at scale, and especially to present the necessary parts of this complexity to their users, the application operators.
In line with Priyanka's users, our most important secondary persona is Allison (Application Operator).
As our primary target customers are enterprise customers, we want to make sure that regulatory and compliance requirements related to application delivery are covered from the start. As a result, we pay special attention to the needs of Cameron (Compliance Manager) and Rachel (Release Manager).
and Ingrid (Infrastructure Operator).
Our investment will focus on two strategic pillars.
In 2021, we have seen that Kubernetes has officially gone main stream.
There are two compelling reasons why we want to be Kubernetes first (not Kubernetes only).
First, we have seen that our customers are reaching out to GitLab after they have decided to modernize on Kubernetes as a platform. With the clear impetus to modernize, we want to meet our customers where they are at and provide capabilities that enable them to benefit from their modernization efforts.
Second, targeting Kubernetes enables us to be more efficient. As Kubernetes becomes more and more ubiquitous, building against Kubernetes is a shortcut around building specific integrations with cloud vendors. We now also have the foundational tool, the GitLab agent for Kubernetes to take advantage of the Kubernetes ecosystem. Given that the agent has permission to act within the cluster, we can enable integration with the rich ecosystem of K8s tools to enable powerful workflows all from within GitLab, while following Kubernetes' operator pattern. With it, we can do exciting things like connect GitLab environments to the actual environment of the running application. Lastly but not least, Kubernetes is API driven. As such, we can move fast building on top of Kubernetes, instead of complicated undertakings such as figuring out how to connect with load balancers.
Deployments and releases always happen outside of GitLab, a target infrastructure that we call an environment. We want to make GitLab environments a central part of GitLab similar to merge requests. Environments should support automation, enable transparency and collaboration in each of the steps that lead up to a release across environments. We plan to focus on improving the connection between releases, environments, Kubernetes clusters. We want to enrich the current environments views with all the related data from security scans, through Observability to DORA metrics.
Our strategy insights are captured in the following SWOT analysis
GitLab has a market-leading CI/CD solution. Deployments and releases using GitLab's CI/CD pipelines work well for many use cases. GitLab users love the developer enablement provided by our robust pipeline definition language, but they find it painful to write and manage hundreds of lines of code to describe their custom delivery logic. Similarly, orchestrating large deployments across projects is painful with GitLab. This complexity is exacerbated by the complexity of infrastructure and the delivery domain. Customers today look for alternative solutions, like FluxCD to hide some of the complexity from software engineering teams.
Independent software deliveries - for the delivery of individual projects that can be deployed in an automated fashion without coordination, developers deploy using CI/CD pipelines in the following ways:
Kubernetes deployments - for deployments to Kubernetes, we have support for pull-based GitOps via the Kubernetes Agent and FluxCD, while push-based GitOps is supported by CI/CD tunnel. Supporting both push- and pull-based deployments, GitLab can be used to migrate to full GitOps approaches of Kubernetes management and can support even dynamic use cases that pull-based only approaches struggle supporting.
Visualising deployment status - once a deployment reaches its target infrastructure, application operators want to make sure that it's running smoothly and serves its users, and they want to be able to troubleshoot issues if needed. GitLab offers a minimal UI to show the status of deployments in Kubernetes.
Orchestrated delivery - for complex releases, particularly those that require orchestration across multiple projects, release managers use Releases to gather artifacts. Sometimes release managers collaborate on the delivery process using GitLab's release.
Continuous Delivery - many industries have strict regulatory requirements to follow that direct them to Continuous Delivery practices. GitLab supports Continuous Delivery via Protected environments and Deployment approval rules.
None of these methods are duplicative and each serves different use cases.
The FY25 financial year runs from February 2024 to the end of January 2025. We will continue our focus on maintenance of existing functionality to ensure the stability of our offerings.
We plan a major redesign of the Environment pages. The current design was built iteratively and information got sometimes added where it was easy not where it made sense. We are rethinking the current layout to fix the suboptimal results of the aforementioned iteration and provide the foundations for more information to be highlighted on these pages in the future.
We continue building out visualisations for Kubernetes in the GitLab UI. We want to reach to a state where application operators can debug their applications in non-production environments through the GitLab UI. Production environments are in scope as a cross-section collaboration with the Analytics Observability group who own historical log storage and querying.
To further integrate Flux, we plan to simplify Flux management by using the agent for Kubernetes to manage all tokens needed by Flux.
We are looking into shipping AI support for troubleshooting Kubernetes issues with Duo Chat, and into shipping an opinionated application delivery framework, the successor of the Deploy component of Auto DevOps.
We decided to drop our in-house GitOps solution in favor of a Flux integration. Our plan is to provide value-add on top of a stand-alone Flux installation by:
Together with some other changes, we want to reach a point where we can finally remove the deprecated certificate-based integration.
Environments today are a light-weight and hidden mirror of your infrastructure status. We want to make them central for DevOps people to rely on when they start their day, want to understand what’s running where or want to change the state of an environment.
While today users can use GitLab CI to code their delivery pipelines, they have to maintain the custom logic. We want to offer a fully declarative and flexible definition to describe delivery pipelines. We call this the GitLab Delivery Framework.
The framework is currently in the planning phase. More details are shared on the Deployment management direction. In line with our Kubernetes first strategy, first, we want to add support for delivery pipelines targeting Kubernetes, later followed by other deployment and release targets.
The framework should:
There are important things we won't work on to focus on our one year plan.
At the same time, we are looking into extending GitLab functionality in some of these areas through partner integrations.
Enterprises are increasingly choosing to have a cloud-first strategy. Furthermore, with the increasing adoption of microservices architecture and infrastructure as code, traditional release tools are inadequate. This, coupled with the traditional delivery requirements of governance, compliance, and security, means that delivery tools have to meet a high bar and address a set of evolving technology and compliance requirements. The primary themes for these capabilities are that first organizations need collaboration and transparency, then control and compliance and before requiring measurement and advanced patterns. We list these key capabilities of deployment platforms in priority order of user need:
Collaboration and Transparency
Control and Compliance
Measurement and Advanced Patterns