このページの情報は古くなっている可能性があります。 最新の情報は 本家サイト でご確認ください。
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.
Additionally, Continuous Delivery serves as the "Gateway to Operations" for GitLab, unlocking the downstream features such as the Configure and Monitor stages.
We follow the well-known definitions from Martin Fowler on the difference between continuous delivery and continuous deployment:
Source: https://martinfowler.com/bliki/ContinuousDelivery.html
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.
The Auto Deploy jobs within Auto DevOps are maintained by the Continuous Delivery category.
Today, in order to reuse a deploy key between several projects, you need to add a deploy key to every project manually. Deploy keys can be used to clone/fetch other repositories that are internal or private.
In gitlab#14729 we are introducing Group deploy keys. This will allow you to configure a single deploy key that can be used by all projects associated to a group.
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:
CI.yaml features
Cloud Deployments
Observability
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.
As far as CD specifically, Microsoft has always been strong in providing actionable metrics on development, and as they move forward to integrate GitHub and Azure DevOps they will be able to provide a wealth of new metrics to help teams using their solution. We can stay in front of this by improving our own actionable delivery metrics in the product via gitlab#7838.
Harness is a modern, cloud-native CD platform that provides excellent solutions for delivering to cloud environments using native approaches like Kubernetes. Additionally, it manages the deployment all the way through to monitoring, which we will introduce via gitlab#8295. We are planning to conduct research on Harness and invite you to chime in on the issues and provide your insights and feedback as well.
Spinnaker is an open-source, multi-cloud continuous delivery platform that helps you release software changes. It combines a powerful and flexible pipeline management system with integrations to the major cloud providers and treats deployments as a first-class citizen. However, it also has a weakness that it does not support other stages of the DevOps lifecycle (such as Continuous Integration), while GitLab offers a single tool for your Development needs.
Our goal is to do make it so anything that Spinnaker can do, can also be done via built-in features in GitLab CD.
Spinnaker's advantage points are:
One analysis of GitLab vs. Spinnaker can be found on our product comparison page. There is another high quality one from our VP of product strategy in gitlab#197709. Finally, our PM for this section completed one where which can be found at gitlab#35219. Our next step is to review these and combine in this section of this document as the single source of truth, exhaustively listing the issues we plan to deliver to reach functional parity (or better) with Spinnaker.
We also respect our customers choice to use Spinnaker's CD solution together with GitLab and are working on making that integration easier with gitlab#120085.
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.
We invite you to follow our plans to natively support hypercloud deployments and Serverless to offer feedback or ask questions.
Users are looking for the ability to not just measure platform stability and other performance KPIs post-deployment, but also providie 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.
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 will start by showing alert on the environments page, in case an error threshold is crossed in gitlab#214634 and will iterate on this by adding a button that will allow you to cancel the deployment via gitlab#216949.
Our most popular customer issue is gitlab#14729 which introduces group deploy keys. Today, you need to add a deploy key to every project manually, so the runner will get permission to clone/fetch the other repos that are internal or private. Group deploy keys would make it easier by allowing you to add a deploy key on the group level that would propagate automatically to any project in the group.
Allowing forked pipelines to run in a parent project via gitlab&3278 is our most popular intrnal customer issue. It will especially help us verify that community contributions live peacefully with our tests before merging them. We will start solving this with gitlab#217451 which will allow forked pipelines to create a pipeline in the parent project but only a user with appropriate permission in the parent's project will be able to run this and merge it.
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.