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.
There is nothing more valuable than user feedback in production. Deployment is the step which brings coded, integrated, and built software to production environments so you can start receiving that feedback. Deployment is part of GitLab's Ops section.
Deployments are increasing in form and freqency.
One side effect of this evolution is that the line between the configuration of infrastructure and the release of software has been blurred. In order to clearly communicate our vision and strategy for these stages, GitLab's deployment direction is inclusive of both the Configure stage and the Release stage to account for the advancement in deployment practices.
GitLab's Deployment vision is to enable deployment to be fast and easy, yet flexible enough to support the scale and operating model for your business.
We want you to spend the majority of your time creating new software experiences for your users instead of investing time and effort on figuring out how to get it into their hands. No matter if you are operating your own infrastructure or are cloud-native, GitLab is your one stop-deployment-shop from AutoDevOps to building your organization's own platform-as-a-service.
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 a much bigger potential. For example, for continous 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. Advanced deployments, GitOps, infrastructure provisioning, platform as a service, 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.
Enterprises, to increase deployment frequency and be competitive in market, 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 DIY platforms, open-source point deployment solutions (such as Flux or ArgoCD) often become the primary option for deployments.
The CI/CD pipeline is one of GitLab's most widely used features. Many organizations that have adopted the GitLab pipeline also use GitLab for deployment because it is the natural continuation of their DevOps journey.
AutoDevOps is a unique GitLab offering that enables users to get up and running quickly and easily yet maintain control of each step of the DevOps process.
There are plenty of spaces where GitLab can improve. There are users who choose to integrate additional point solutions or deployment platforms because GitLab is lagging in some key capabilities. We view cloud-native disruption as a competitive threat.
The Ops section challenges are applicable to deployment. There are some challenges that are worth expanding on with some additional highlights:
The Ops section opportunities apply to deployment. GitLab also has some important tail-winds specific to deployment:
Enterprises are increasingly choosing to have a multi-cloud 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 technical and organizational requirements.
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 by focusing on two strategic vectors.
First, we want to make it easy to deploy to Kubernetes. Kubernetes is growing fast and also is a short-cut 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.
Second, we want to make it easy for Priyanka to know she is doing a good job. GitLab is uniquely positioned as a solution to visualize how well teams are shipping software. Helping her in this way enables her to focus on the next thing to enable her customers, the development teams. It also helps her argue for more investment from her leadership, which leads to bringing more customers to GitLab.
By executing on this sandwich strategy, and leveraging the fact that the GitLab CI/CD is the default pipeline workflow for development teams already today, we aim to make adoption of additional deployment features more efficient.
The majority of smaller companies with singular deployment targets and simpler collaboration concerns do not need anyone to act as a Platform Engineer. We believe that setting sane defaults for GitLab's deployment features will fit their needs.
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.
Actively adding templates or improving existing templates is not our main focus. The CI/CD pipeline is flexible and enables GitLab users to create what they need as is. It may be worthwhile to examine how we can enable the wider GitLab community to share and reuse similar templates and treat them as lego blocks that can be adopted and put to use quickly. However, it is not our focus right now.
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.
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.
