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.
We recently released support for parallel Merge Trains (gitlab#11222). After using this internally, we discovered that some tweaking is needed in order to use this in a widespread manner, our first concern is performance, that is why we are working on gitlab#31692 tuning the concurrency of the number of merges in a single train.
Another exciting feature that we are working on is to allow fork pipelines to run in parent project (gitlab#11934). Some development teams are forking instead of a branching git workflows. We want to provide a way to run a pipeline in this way, with the appropriate security considerations accounted for that will support these CI/CD projects as well.
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.
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#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
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-org#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.