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, is 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 part of GitLab's Ops section. 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 guard rails set by operators. In overcoming these hurdles, teams must:
Ephemeral infrastructure blurs the line between infrastructure configuration and software release. As a result, we include our Configure and Release stages in our Delivery direction. 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. Martin Fowler defines these related terms as follows:
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 making the hardest part of DevOps - software delivery - easy, flexible and secure.
We will accomplish this by
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). 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 set 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 auxilliary 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.
In Delivery, we are targeting the central platform team personas in 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.
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 enables 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, building on top of Kubernetes easily allows us to implement things like advanced deployments.
Deploying modern applications is complex. As one of the last steps in delivering change to users, it is imperative to support automation and enable transparency and collaboration in each of the steps that lead up to a release. We plan to focus on improving the connection between releases, environments, Kubernetes clusters, Observability and integrating with GitLab CI/CD and DORA metrics for a full user experience.
The delivery direction primarily affects the Configure and Release stages. Given the scope of work, we want to deliver the integrations in alignment and with the support of the Package, Monitor, Secure, Verify and Manage stages.
GitLab has a market-leading CI/CD solution. Deployment and release using GitLab's CI/CD pipelines work well for many use cases. In particular, CI/CD pipelines are great for individual projects which deploy independently. 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.
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 usecases 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.
GitLab supports modern, GitOps deployments to Kubernetes using the agent for Kubernetes; custom-built deployment and release pipelines are supported on top of GitLab CI/CD for legacy infrastructures.
We are working on a few key themes:
We want to measure our success by focusing on the combined SMAU metric of the Configure and Release stages.
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.
Complex, large-scale deliveries need orchestrated releases, aggregated insights and management with the possibility to drill down to the details.
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.
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.
Waypoint, by Hashicorp, provides a modern workflow to build, deploy, and release across platforms. Waypoint uses a single configuration file and common workflow to manage and observe deployments across platforms such as Kubernetes, Nomad, EC2, Google Cloud Run, and more. It maps artifacts to runtime after the test and build phases. Waypoint sits alongside the source code, and enables declarative deployment - it takes the manifest of how the platform is configured and will execute the steps sequentially unique for each platform. Waypoint can be used with GitLab CI and even with the Auto DevOps workflow with deployments being done by Waypoint.
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.