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, we are targeting the central platform team personas, Priyanka (Platform Engineer) and Ingrid (Infrastructure Operator). They are responsible for setting up the systems that development teams use to develop, test, ship, and operate their applications. It is likely they work at an enterprise where there is a mix of delivery targets. 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.
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.
GitLab has a market-leading CI/CD solution. Deployment and release 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.
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.
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.
None of these methods are duplicative and each serves different use cases.
The FY24 financial year runs from February 2023 to the end of January 2024. Early in 2023, we made the decision to integrate Flux as our go-to GitOps tool, instead of our homegrown solution. We will dedicate much of our time to build out an easy to manage and use integration around Flux.
As outlined above, we are looking into turning GitLab environments to a central place of GitLab to - well - learn about environments. This includes adding an integrated cluster view, providing environment views and actions at the group level and enriching the current environment pages with related data.
Following the above themes, we will start work on a conventions-based delivery framework built on the strengths of GitLab, its source code management and pipelines.
To measure success, we want to introduce new metrics, like the number of GitOps sync events and interactions with the environments pages. Until these metrics become available, we track our performance via the CI/CD workflow MAU metric and the SaaS-only environment metrics.
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 your 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.
The Ops section challenges are applicable to delivery. Some challenges are worth expanding on with some additional highlights:
The Ops section opportunities apply to delivery. GitLab also has some important opportunities to take advantage of specific to delivery:
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
GitHub Actions are an automation workflow integrated with GitHub repositories. Each action is triggered by one or multiple events. Using GitHub Actions, users can define any number of jobs, including deployment jobs. Microsoft has setup actions to be like lego pieces, and has built a workflow around finding and reusing actions in an actions marketplace.
GitHub Actions recently introduced environments which can help users set specific rules based on environments to automate deployment workflows. Furthermore, environment scoped secrets enables different secrets for different tiers, separating deployment from development to meet compliance and security requirements.
The Tanzu Application Platform is a full-fledged solution for delivery management that ships with Tanzu Kubernetes clusters.
Harness is a modern, ambitious CI/CD platform that can be a single platform to build, test, deploy and verify any application. Read more about Harness in our DevOps tools comparison page.
Spinnaker, born out of Netflix, is an open-source, cloud-native, multi-cloud continuous delivery platform for releasing software changes.
It views its solution in three parts. First, application management which enables users to visualize and manage cloud resources. Second, application deployment is a powerful and flexible pipeline management system with integrations to the major cloud providers and treats deployments as a first-class citizen. Lastly, managed delivery combines application management and delivery, and enables users to specify what they want in declarative format.
Spinnaker's advantage points are:
There is additional analysis that can be found in gitlab#197709 and in gitlab#35219.
Argo CD is part of the Argo Project which is a incubation project in CNCF. Argo CD is a declarative, GitOps continuous delivery tool for Kubernetes. Argo CD is installed as an application in its own namespace in a cluster. Optionally, you can also register additional clusters to do multi-cluster deployments.
Beyond enabling users to practice GitOps, Argo CD does a great job reporting and visualizing the differences between your target state and live state, which greatly facilitates learning and understanding for operators.
Combined together with the other Argo Project capabilities, including Workflow, Rollouts, and Events, using Argo is a fairly complete way to manage the entire Kubernetes Development lifecycle.
Weaveworks positions itself as a Kubernetes platform, enabling devops teams to do GitOps, to manage cluster lifecycles, and to monitor applications. Weaveworks operates a SaaS solution that operates the various open source projects it maintains. Of the open source tools, particularly notable in the deployment context is Flux which enables GitOps, Flagger which enables canary deployments. Scope which enables visualization of Kubernetes, and Cortex which enables monitoring.
We decided to integrate Flux into the GitLab offering. We think of Weaveworks as a partner and are looking for possibilities to best serve our shared customers.