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.
Many teams are reporting that development velocity is stuck; they've reached a plateau in moving to more and more releases per month, and now need help on how to improve. According to analyst research, 40% of software development team's top priorities relate to speed/automation, so our overriding vision for Continuous Delivery is to help these teams renew their ability to accelerate delivery.
We follow the well-known definitions from Martin Fowler on the difference between continuous delivery and continuous deployment:
Infrastructure Provisioning and Infrastructure as Code, using solutions like Terraform or other provider-specific methods, is an interesting topic that relates to deployments but is not part of the Continuous Delivery category here at GitLab. For details on solutions GitLab provides in this space, take a look at the category page for our Infrastructure as Code team.
For deployment to Kubernetes clusters, GitLab has a focused category called Auto DevOps which is oriented around providing solutions for deploying to Kubernetes. Check out their category page for details on what they have planned.
We are working on a similar experience for non Kubernetes users, starting with Streamline AWS Deployments that will automatically detect when users are deploying to AWS and will connect the dots for them.
As part of our effort to support DORA 4 Metrics in GitLab, we introduced project level Lead time for changes metrics and deployment frequency both at the API project level and charts that can be found under the Analytics-CI/CD page. We are now working on intorducing group level deployment frequency charts via gitlab#291748 and will continue to add support for the rest of the DORA4 metrics.
To increase deployment safety, and to help large organizations with many projects to ensure deployments can only be proceeded by the right group at the right time, we are working to add group-level permissions to protected environments.
This category is currently at the "Complete" maturity level, and our next maturity target is Lovable (see our definitions of maturity levels). Key deliverables to achieve this are:
Auto Deploy (AutoDevOps Flow)
Because CI and CD are closely related, the competitive analysis for Continuous Integration is also relevant here. For how CD compares to other products in the market, especially as it relates to pipelines themselves, also take a look there.
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:
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.
In our conversations with industry analysts, there are a number of key trends we're seeing happening in the CD space:
Cloud adoption of CI/CD is growing, extending capabilities for deploying to cloud environments, including Kubernetes and other modern container architectures are a key metric. While cloud migration is accelerating and more teams are adopting it, on-premises and legacy hardware environments remain.
Users are looking for the ability to not just measure platform stability and other performance KPIs post-deployment, but also provide functionality such as automated release-readiness scoring based on analysis of data from across the digital pipelines. Tracking and measuring customer behavior, experience, and financial impact, after deployment via gitlab#37139 solves an important pain point.
Metrics are a primary source of quantifiable feedback, which is a key objective of agile and DevOps methodologies. Development teams that collect and analyze metrics understand successes, failures and opportunities for improvement better than their peers. Mature development teams actively monitor metrics data and compare results against baselines, which can be industry benchmarks or constant improvements against past results of the individual team. We are actively working on supporting DORA4 metrics as an integral part of GitLab which will allow you to gain efficincy and stability insights into you softwarre development lifecycle.
Progressive Delivery allows you to deploy code incrementally and target the audience that will receive the new code based on user segments and environments. By doing so, it enables experimentation with reduced risk. Progressive Delivery builds on the foundations laid by Continuous Integration and Continuous Delivery. Related categories to this theme are Feature Flags and Advanced Deployments. To read more about this see RedMonk's post.
The ability to monitor deployments and automatically halt/rollback deployment in case of exceeding a specific error rate is frequently mentioned by CS and in the sales cycle as a feature teams are looking for. This will be implemented via gitlab&3088. We have recently added the ability to rollback automatically in case a critical alert is raised via gitlab#35404 (Complete) and will follow up with adding a notification when an auto-rollback accord via gitlab#292019.
The most requested customer issue is gitlab#5902 which adds the ability to create Deploy Tokens with functionality similar to the Deploy Keys, where the admin can create and assign Deploy Tokens per project which will grant non-personal registry-only access to the images without needing an extra seat.
Adding a check for maximum commits before merge via gitlab#26691 is our most popular internal issue. This adds a validation check, to make sure that your merge request is not too far behind master before merging in order to avoid breaking master
Our top vision item is to Natively support hypercloud deployments, and specifically deploying to AWS we want to help make it easier and quicker to get started and deploy to any one of the big cloud providers using GitLab's CI/CD.
We are planning to research user needs for multi-cloud deployments. If you are interested in participating in this user research, please leave a comment in ux-research#1249.