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.
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:
Enable Developers: Deployment is simple when done alone. It's hard when done across hundreds of development teams. Doing it well requires automation, orchestration, coordination, and collaboration.
Increase Frequency: Rate-of-iteration is a competitive advantage. Products must deploy frequently to capture value sooner. Increasing deployment frequency compounds the stress on teams responsible for deployments. Teams need fast, repeatable, and safe ways to deploy.
Accommodate Target Variety: Deployment used to involve copying new files to a specific server. Today, deployment targets span environments (dev/staging/production), infrastructure types (VM and container). Adding to the complexity, these environments and their infrastructure are ephemeral. Operations teams need to provide a consistent interface for deploying to different targets.
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
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
Empowering platform engineers to define and automate DevOps practices that have security and compliance guard rails built directly into the process. By empowering the platform engineer Priyanka, she, in turn, enables developers to own their specific deployment operations without toil, yet retain flexibility and efficiency.
Enabling developers to deploy applications consistently and frequently in a compliant, reliable, and repeatable way, no matter the deployment target(s) you've defined or how you've organized your applications and teams.
Taking advantage of the data available in the connected GitLab platform, from planning input to observability and incident data, to make deployment operations, such as scaling rollouts or rollbacks automatic.
Market
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.
Current Position
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:
Custom pipeline can take advantage of functionalities made available in containers, including ones published by GitLab
Including pipeline definitions provided by their platform teams
Using GitLab provided deployment templates (such as Pages, AWS, Fastlane, Serverless, 5 Minute App, etc)
Utilizing GitLab's AutoDevOps defined deployment process
Kubernetes deployments - for deployments to Kubernetes, developers use custom CI/CD variables when writing pipelines that deploy to attached Kubernetes clusters. We recently added support for pull-based GitOps via the Kubernetes Agent.
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:
Independent Deployments by providing better tools for publishing and utilizing defined deployment pipeline definitions within organizations
Orchestrated Deployments by adding the ability to manage shared environments, sequence deployments, implement approval gates, and visualize the deployment workflow across the organization
We will also create clarity in the deployment options and retain our focus by:
Remove GitLab provided templates that aren't used
Deprecate any customized deploy images
Limit the applicability of Auto DevOps to Kubernetes based-deployments
Challenges
The Ops section challenges are applicable to deployment. Some challenges are worth expanding on with some additional highlights:
CNCF/cloud-native open-source solutions can disrupt GitLab's one application vision. They are marketed to a huge and engaged audience. If they're successful in growing adoption, it introduces a barrier to adopting GitLab. For deployment, a risky and highly visible part of the SDLC process, organizations may be more reticent to switch to GitLab's one application solution.
GitLab's pipeline-based deployment solution targets the developer as the primary persona. As a deployment tool, it may be less effective relative to solutions that target the operator as the primary persona with specific tooling made for their primary jobs.
Opportunities
The Ops section opportunities apply to deployment. GitLab also has some important opportunities to take advantage of specific to deployment:
GitLab is well positioned to help: GitLab has a significant advantage for organizations already utilizing GitLab CI/CD. While deployment is not the same as the fully automated pipelines prescribed by Continuos Delivery GitLab customers are already used to defining their automation directly within their DevOps Platform. Beyond being adjacent, GitLab's single platform can make collaboration and feedback from deployments smart, faster and more actionable.
Cloud-Native requires new tools: When organizations make a determination to move toward Kubernetes, this often becomes an opportunity to modernize their deployment toolchain. They want a tool that can help them deploy, manage, and operate their clusters. GitLab is well-positioned to help DevOps teams automate and manage Kubernetes deployments.
Key Capabilities for 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
Environment management: Organizations typically operate multiple environments, each serving different needs. Deployment tools should help to make managing environments easy and intuitive.
Everything as code: Deployment tooling, including pipelines, infrastructure, environments, and monitoring tools, are constantly evolving. If they can be stored as code and version-controlled, it will enable organizations to more effectively collaborate and avoid costly mistakes.
Control and Compliance
GitOps: Simply checking code into a repository will not prevent drift to occur between code and what is deployed. GitOps solves this problem by automatically managing changes using the single source of truth reflected in the source repository providing more control by preventing drift.
Release Orchestration & Quality gates: Organizations need to control what can be deployed and in which sequence. Enabling reviews and approvals built right into the deployment workflow is a critical requirement. The ability to perform automatic rollback, environment freeze, and scaling deployment also enables organizations to be more in control.
Measurement and Advanced Patterns
Feedback/Reporting: Deployment is a critical part of the DevOps feedback loop. A successful deployment depends on both immediate feedback from Monitoring and Observability tools to ensure a healthy deployment. Monitoring the performance of DevOps teams, such as the DORA4 metrics will also lead to improvements over time.
Progressive delivery: Deployments can be risky. To mitigate risks, progressive delivery techniques, such as using feature flags, canary and rolling deployments can help mitigate the risk by limiting the impact until the deployment teams are confident that their changes are good to go.
Strategy
In Deployment, we are targeting Priyanka (Platform Engineer) as our primary persona. She is responsible for setting up the systems her company's development teams use to develop, test, ship, and operate their applications. It is likely she works at an enterprise where there is a mix of deployment targets. She 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. She is looking for ways to create a system to manage the complexity.
We plan to iteratively create a solution that addresses priority needs of collaboration and transparency before beginning to focus on control and compliance. We'll do that by focusing on two pillars. We want to make it easy for Priyanka to:
Enable her developers to deploy to Kubernetes. Kubernetes is growing fast and also is a shortcut around building specific integrations with cloud vendors. Kubernetes is an efficient target for deployment. It is also where deployment innovation is happening fastest. It is important that we mitigate this low-end disruption and make deployments to Kubernetes that work by default.
Control her organization's deployment process. GitLab enterprise customers may strive for progressive delivery and other advanced deployment features, however we can't expect enterprises to immediately hurdle release challenges that come along with their traditional deployment targets. Their current challenges are with more controlled release processes and the coordination, collaboration and compliance required when orchestrating releases. We want to solve for these initial needs first by providing a great Release Orchestration UI within GitLab. This is how we can facilitate the Golden Journey from Verify to Release.
One Year Plan
To execute our strategy, we are creating two new categories:
Environment Management - Within GitLab today, Priyanka manages environments by defining them directly in gitlab-ci.yaml. This works well when she is managing environments per project, but not when she is managing central platform environments that have multiple applications deploying to them from separate projects. She needs visibility to the environments and the deployments to those environments from across multiple projects.
Delivery Platform - Within GitLab today, Priyanka uses gitlab-ci.yaml templates and snippets to publish deployment best practices for the developers she supports to use. This works when the number of projects is small, and the infrastructure and deployment patterns are sufficiently common. It becomes painful when Priyanka is attempting to define the complex infrastructure and multiple deployment methods across a larger number of teams. It becomes even more complicated when she tries to understand the status of deployments across multiple development teams. Priyanka needs a way to enable multiple teams to follow the best practices she defines across multiple projects and track their deployment status with ease.
And continue our progress on current capabilities:
Kubernetes Management - We've recently adjusted our approach to connecting Kubernetes clusters to your GitLab instance (with the Kubernetes Agent). We will continue to add agent-based, cross-project cluster management capabilities that target Priyanka's pain points when managing centralized Kubernetes clusters.
Release Orchestration - We'd previously made investments in improving the experience for more traditional release engineering processes. We are restarting this investment to provide a foundation for platform teams who need to participate in a centrally coordinated release effort. We will shift our focus to enable Priyanka to control access to specific environments and to set up approval workflows. We will also enable Priyanka with tools to set up release managers to organize releases from multiple projects that will be deployed together.
Infrastructure as Code - We've made considerable improvements to the way you manage your infrastructure with Terraform from within GitLab. We will continue to build capabilities for sharing, collaborating, and enabling developer use of infrastructure definitions provided by platform teams.
Measure Success - GitLab is uniquely positioned as a solution to visualize how well teams are shipping software. Surfacing important health metrics, such as the DORA4 metrics, will help fuel improvement and adoption of additional GitLab features.
What we aren't focused on now
There are important things we won't work on to focus on our one year plan.
Auto DevOps Deployments - While we will enable the creation of Auto DevOps style templates and experiences for the developers in their organization by platform teams, we will not be making significant strides to make Auto DevOps deployments cover a broader set of use cases at this time.
Progressive Delivery - By focusing on where platform teams are today, we'll forgo pushing further on our current progressive delivery capabilities like Feature Flags, A/B Testing and Canary Deployments.
Cost Optimization - We should first improve adoption of our Kubernetes Management capability before focusing more on cluster costs. Enterprises want views into costs beyond clusters. Building capabilities like environment management precedes cost optimization tooling.
Non-Kubernetes Cloud-native - Distinguishing from Kubernetes-native, which is our initial focus area. We will not be focused on other cloud-native solutions, such as Docker Swarm, Apache Mesos, and Amazon ECS, because they're not nearly as successful as Kubernetes.
Building more Deployment Methods - Actively adding templates or improving existing templates is not our main focus. Nor is building customized images for deploying to cloud providers. The CI/CD pipeline is flexible and enables GitLab users to create what they need as is. It is worthwhile to examine how we can enable the wider GitLab community, including our customer success teams, to share and reuse similar templates and treat them as lego blocks that can be adopted and put to use quickly. These will be most beneficial for common deployment targets, such as Fargate and Lambda.
GitLab Pages - While the deployment of static sites is a large market, GitLab Pages is more of a fit for sharing static webpages within an organization today. We are exploring how to accelerate deploying static content more generally in the Jamstack SEG
Beyond Release and Configure, Monitor is also an important aspect of operating your production deployments. We will be adding direction content on this topic.
Lastly, within GitLab, the nomenclature for deployments, environments, release, delivery are often inconsistent, interchangeable, and confusing. We need to settle on a standard and build it into our products and documentation.
Jobs To Be done
When deploying my application, I want to orchestrate the entire process, so that the users can use a well-functioning application.
When operating the development platform, I empower engineers while retaining control with SSO, RBAC, Audit trails, secret management, progressive delivery, and auto-scaling deployments and rollbacks.
When a developer is using the development platform, I want the developer to be more productive by not having to spend time figuring out how to deploy yet enable them to comply with security and compliance requirements.
When operating the development platform, I do not want to slow down the development teams and limit what they need to do to improve and deploy their service so that there's no downside to using the platform.
When changing something in my organization's DevOps process, I do not want to create extra work for my development teams yet enable them to still benefit from the improvements in the process.
When managing my environments, I want to see and understand what is currently running, so that I can make decisions on what I need to do.
When deploying my application, it doesn't matter if I am deploying to legacy servers or to Kubernetes, it all just works.
When looking for improvements, I can understand how my organization is performing, so that I can pinpoint actionable improvement areas.
Competitive Landscape
GitHub Actions
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.
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:
Provides easy application deployment across cloud providers. We have also recognised this as one of our top vision items and are working to natively support hypercloud deployments.
Supports several deployment strategies which we are working on expanding in Advanced Deploys.
Allows configuring an environment in standby for easy rollback, which is closely tied to gitlab#35409.
Provides a user interface that allows you to view your infrastructure and to see exactly where your code is residing.
Acts as an operator that performs rollback when needed without the need to provide a script to do so (similar to Kubernetes).
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
Argo CD is a declarative, GitOps continuous delivery tool for Kubernetes. It 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.
Weaveworks
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.
Git is a trademark of Software Freedom Conservancy and our use of 'GitLab' is under license
