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 comment on our async AMA issue, email Kevin Chu 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 because we enable applications to be deployed 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. We do 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. Lastly, GitLab deployment takes 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.
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, 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:
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 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:
To execute our strategy, we are creating two new categories:
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.gitlab-ci.yaml templates and snippets to publish deployment best practices for the developers she support 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 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:
There are important things we won't work on to focus on our one year plan.
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.
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 (with their recent acquisition of Drone.io) is a modern, ambitious CI/CD platform that can be a single platform to build, test, deploy and verify any applications. Harness integrates with tools like Service Now and Jira to enable approval workflows. It integrates with monitoring tools (like DataDog, Splunk or CloudWatch) and applies AI to metrics to automate deployment workflows like rollbacks. Lastly, it is intuitively easy to create dashboards like the DORA4 to provide feedback.
Harness provides a more visual and template based CD pipeline definition process than GitLab, enabling developers get up and running with only a few clicks to complete a end-to-end deployment platform.
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 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 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.
