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.
We would appreciate your feedback on this direction page. Please create an issue to collaborate with us or propose an MR to this page!
Deployment is when you promote a coded, integrated, and built software application to a production environment. Once you deploy an application, users derive value from it. Deployment is part of GitLab's Ops section.
In the journey to become elite DevOps performers, deployment is the hardest challenge. Deployment is where development and operations meet. Deployment 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 config and software release. As a result, we include our Configure and Release stages in our Deployment direction.
GitLab's Deployment vision is to enable your organization to be an elite performer in DevOps by making the hardest part of DevOps - deployment - 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 deployment tooling market is evolving and expanding. There are now many more options than just adding a delivery job to your CI/CD pipeline. Release Orchestration, advanced deployments, GitOps, infrastructure provisioning, platform as a service, progressive delivery, and feature flags are all methodologies that help teams deploy 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 deployment 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. Otherwise, enterprises, even existing GitLab customers, sometimes buy commercial tools for deployment, such as octopus, harness, and CloudBees electric flow.
GitLab has a market-leading CI/CD solution. Deployment 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 ability to define their deployment process as code. They love the developer enablement provided by our robust pipeline definition language.
Independent deployments - for deployments 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. The CI/CD tunnel can also enable a cluster connection to be used from GitLab CI/CD, enabling users to deploy with only minor adjustment to previous setup. Lastly, evelopers can also use custom CI/CD variables when writing pipelines that deploy to attached Kubernetes clusters.
Orchestrated deployment - for complex deployments, particularly those that require orchestration across multiple projects, release managers use Releases to gather artifacts. Sometimes release managers collaborate on the deployment process using GitLab's release.
None of these methods are duplicative and each serves different use cases. However, we will focus on improving:
We will also create clarity in the deployment options and retain our focus by:
The Ops section challenges are applicable to deployment. Some challenges are worth expanding on with some additional highlights:
The Ops section opportunities apply to deployment. GitLab also has some important opportunities to take advantage of specific to deployment:
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 deployment requirement of governance, compliance, and security, means that deployment 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
In Deployment, we are targeting the central platform team personas in Priyanka (Platform Engineer) and Ingrid (Infrastructure Operator). They are responsible for setting up the systems her company's 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 deployment targets. They also faces the challenges of ever-increasing complexity; as more contributors, more services, more infrastructure, more databases, and a mix of technologies are added to her 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 Kubernete's 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 enable transparency and collaboration in each of the steps that lead up to deployment. We plan to focus on improving the connection between releases, environments, Kubernetes cluster, and Observability to enable a streamlined and safe deployment experience.
In 2021, we created this Deployment Direction to better align our efforts on deployment. I'll highlight some key developments from last year.
First, we consolidated the Release group's broad focus. The Release group was building new features in DORA Metrics, investing in a superior GitLab Pages architecture, AWS EC2 deployment tooling, while simultaneously maintaining a broad swath of categories from feature flags to continuous delivery. We spread the group too thin, especially while we were also trying to onboard several new engineers. We shifted the team to focus on enabling teams to collaborate and deploy with GitLab CI/CD pipelines. Furthermore, having invested heavily in reliability and scalability during the second half of last year, we expect the team to be more efficient in 2022.
Second, the Configure group launched the GitLab Agent for Kubernetes for GitLab SaaS in 2021. The agent is an active in-cluster component for connecting Kubernetes clusters to GitLab. The agent enables customers to practice pull-based GitOps and cloud-native deployments. Since we launched the CI Tunnel and made it available in the GitLab Free plan, we have seen a spike in adoption. Despite these accomplishments, progress in cloud-native deployment last year has been slower than we would have liked. The team spent a large part of our capacity helping out with various reliability and scaling activities and deprecating the old certificate-based Kubernetes integration.
In 2022, we plan to bring many improvements to those looking to deploy more frequently. Here are the things I am excited to work on and ship over the next year with my teams:
Building momentum in Kubernetes Management We plan to build upon our cornerstone technology, the GitLab Agent for Kubernetes, to lower the cost and burden of operating Kubernetes. First, we are working on making the agent setup simpler, enabling more users to easily start gaining the benefits of operating in Kubernetes with GitLab. The agent will have improved permissions management, allowing platform engineers and the teams they serve to have the control they desire. We plan to bring back the most useful functionalities that were deprecated with certificate-based Kubernetes integration, such as auto-deploy, GitLab-managed clusters, and deployment boards. Lastly, the advantage of the agent is that it sits within the cluster. As such, we hope to add integrations to the many capabilities available in the Kubernetes ecosystem. For example, the integration with Cilium enables users to see network policy-related alerts directly in GitLab.
Introducing Continuous Verification We plan to introduce the Continuous Verification category, which will enable users to monitor their application after a deployment directly in GitLab. By integrating with monitoring tools or using the out-of-the-box integration with GitLab Monitor capabilities, users can make monitoring feedback viewable, actionable, and automatable. In turn, our users can become much more efficient in their deployment process.
Improving our current deployment capabilities Thousands of users and customers already deploy with GitLab every single day. However, for some teams, this is not easy because GitLab lacks specific deployment workflows, has disconnected user experiences between features, and doesn't make it easy for central platform teams to manage the environments shared between potentially hundreds of services.
Over the next year, we plan to solve many of these problems. We are adding approval workflows for deployments. We are also making environments in GitLab more useful for large teams managing hundreds of services. Lastly, we are looking to make the entire user experience a connected experience—from organizing a release to defining infrastructure as code to packaging changes to deployment.
Enabling managed deployments GitLab enables developers to deploy projects today, but gaps remain. Setting up even a moderately complex deployment pipeline requires large amounts of custom scripting that is hard to maintain, scale, and understand. Moreover, once these pipelines are run, it's hard to track and check the changes caused from start to end.
There are important things we won't work on to focus on our one year plan.
Our focus today in deployment are the following:
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:
One analysis of GitLab vs. Spinnaker can be found on our product comparison page. 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.