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.
Interested in joining the conversation for this category? Please join us in our public epic where we discuss this topic and can answer any questions you may have. Your contributions are more than welcome.
We follow the well-known definitions from Martin Fowler on the difference between continuous delivery and continuous deployment:
One of the key sub-areas within Continuous Delivery that we're tracking is incremental rollout. This is important because it enables unprecedented control over how you deliver your software in a safe way. For these items we're also tagging the label "incremental rollout", and you can see an issue list of these items here. Incremental rollout also serves as a key pillar for our Progressive Delivery strategy.
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.
In short, the Continuous Delivery category will help you deploy the code in your project to your infrastructure; our Infrastructure as Code category will help you create and modify your infrastructure as part of your deployments.
For deployment to Kubernetes clusters, GitLab has a focused category called Auto DevOps which is oriented around providing solutions for deploying to k8s. Check out their category page for details on what they have planned.
GitLab CI/CD was built from the ground up with speed and scalability in mind, and we are always working hard to enable Speedy, Reliable Pipelines. With that in mind, we are currently working on gitlab#15536, which will limit pipeline job concurrency using named semaphores. Sometimes there is a need to limit a resource or environment and this will ensure that there will only be one deployment at a time
Another important theme that we are working on is Do Powerful Things Easily, which includes Natively supporting hypercloud deployments. To start we are focusing on creating base images that will make it easier to use GitLab for deployment to any one of the major could providers, starting with Streamline AWS Deployments, even when not using Kubernetes.
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:
Because CI/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, 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-ee#7838.
Spinnaker and Harness are also two modern, cloud-native CD platforms that provide excellent solutions for delivering to cloud environments using native approaches like Kubernetes. In order to remain competitive, we must provide more advanced deployment operator solutions via gitlab#1387. Additionally, these products manage the deployment all the way through to monitoring, which we will introduce via gitlab#8295.
We are conducting 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. Spinnaker is a great CD tool, but it does not support other stages of the DevOps lifecycle (such as Continuous Integration), while GitLab offers a single tool for your Development needs. Some of Spinnaker's advantage points are:
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, with Docker adoption leading the way and serverless likely next. People need guidance solving CD because they are stepping out into the dark without mature solutions already available to them; for example, AWS' current solution for serverless (functions) CI is just "edit them live." Customers complained that their products were starting to feel legacy, but where they go next is unclear.
We invite you to follow our plans to natively support hypercloud deployments and to offer feedback or ask questions.
Customer experience is becoming a key metric. Users are looking for the ability to not just measure platform stability and other performance KPIs post-deployment but also want to set targets for customer behavior, experience, and financial impact, as part of gitlab#37139. Tracking and measuring this indicators after deployment solves an important pain point. In a similar fashion, creating views which are managing products not projects or repos will provide users with a more relevant set of data.
In addition to supporting the trends above, there are some key areas where we can focus that will improve our solution in areas that analysts are hearing customer demand:
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#8295.
Our most popular customer request is gitlab#15536, When there are consecutive deploys to the same environment, it may cause unwanted problems. We are working on an ability to allow users to limit concurrency to prevent simultaneous deploys from different projects to the same environment.
Our most popular internal customer issue is adding a way to notify the user about the maximum commits behind the source branch gitlab#26691, this will reduce the risk of breaking master and let the user know that he/she should rebase before merging.
In an effort to dogfood our own features, we are actively working on using merge trains internally on gitlab-org gitlab#195 A design document is coming from delivery team for the actual process. we can use this to see how this would be modeled in GitLab; see also the CI/CD Blueprint
Our delivery team is also working on gitlab#35741 which displays the deployment information on the merge request, including when the first deployment took place, and also will tell you for a specific deployment which merge requests were merged.
From an SRE standpoint, see:
Our top vision item is to Natively support hypercloud deployments, 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.