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 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, 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:
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.
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.
Continuous verification (currently not a product category) is the collection and analysis of data to ensure the application performance is within predetermined quality limits. Practically, this means monitoring your application for abnormalities after a deployment. We plan to enable teams to practice continuous verification using GitLab's new observability capabilities. We also recognize that teams may have alternative preferences for their monitoring or observability platform. We plan to start building a vendor-agnostic experience, that enables the same continuous verification experience all within GitLab.
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.
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.
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.
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.
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 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.