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.
Now that we have delivered gitlab-ee#7380, the ability to run a pipeline against the potential merge result, we're able to take the next step towards merge trains via gitlab-ee#9186. This will allow for a merge train to be set up where a series of MRs are queued up, one after the other, and merged in sequence against the merge result. This will create a very safe, reliable way to deliver your MRs.
The one drawback with this first iteration is that it is slow - one at a time can result in long queues in a lot of different situations, so we plan to immediately follow this up with gitlab-ee#11222 which will introduce parallalization to merge trains.
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.
Microsoft is planning to use their GitHub acquisition to pick up open source market share. There had been a trend to move away from them because users saw their current development tools as old-fashioned; with rebranding them to Azure Devops (and investment in improving their capabilities) they are trying to disrupt this decision by their customers.
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-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 control pipeline concurrency in an environment (especially later ones such as production or staging) is frequently mentioned by CS and in the sales cycle as a feature teams are looking for. This will be implemented via gitlab-ce#20481.
Our most popular customer request is gitlab-ce#20481, which limits per-environment pipeline concurrency. This is an important feature because it allows teams to constrain concurrent deployments, making things more predictable and/or managing finite resources associated with environments (for example, a single deploy and test cycle at a time to a performance testing environment.)
Finishing merge trains via gitlab-ee#9186 will allow our own engineering teams to be more effective while maintaining a stable, releasable master branch.
The Delivery team at GitLab is moving towards CD with https://gitlab.com/gitlab-org/release/framework/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 a SRE standpoint, see:
Beyond completing the 2018 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.