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.
Pipelines for merge requests/results introduced a nice new feature that allows you to run a pipeline in the context of a merge request, but the only way to trigger these is through a push. We understand the need to re-run or trigger a new pipeline for a merge request manually. So, that's why we are working on delivering the ability to re-run a merge request without having to push a new commit. (gitlab-ce#65940), Sometimes a user needs to re-run a merge request pipeline with the latest master (target branch) for an MR that has not been updated.
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:
Additionally, we are considering cloud-native buildpacks as the foundation for Continuous Delivery. Depending on how that project plays out, it may play an important role here - in the meantime we are monitoring that project for progress.
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-ee#1387. Additionally, these products manage the deployment all the way through to monitoring, which we will introduce via gitlab-ee#8295.
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.
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. Tracking and measuring this indicators after deployment solves an important pain point. In a similar fashion, creating views which 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-ce#8295.
Our most popular customer request is gitlab-ee#20481, 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.
We currently do not have internal customer issues open.
The Delivery team at GitLab is moving towards CD with https://gitlab.com/gitlab-com/gl-infra/delivery/issues/1. That issue is intended to capture items that are important for that effort, and other use cases and information that can lead into a better CD product for our users as well as successful migration to CD at GitLab. 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
We are also working to internally adopt some recently released features:
From an SRE standpoint, see:
Beyond completing the 2019 vision, the most important major step forward for GitLab CD is gitlab-ee#8295 which will introduce post-deployment monitoring, creating a foundation for advanced deployment features like automated rollbacks and summary reports of environment behavior before and after the deployment.