Accelerate Software Delivery

Software, in so many respects, is the lingua franca or currency of the modern age. Whether it’s an e-commerce site for a small startup or infrastructure software for a stock exchange, software not only has to be designed and developed, it also has to be delivered before customers can use it.

CI/CD

Why Is It Important?

No matter what business you’re in, being able to deliver software – and software changes – at a consistently faster pace than your competitors gives you a strong competitive advantage.

Yes, you may have a fantastic concept, but if no one can use it, or your competitors are able to iterate faster, it may as well not exist. So you need to progressively accelerate your ability to deliver.

What KPI Should You Track?

The core KPI to track is PR Cycle Time. It measures the time taken from when a developer started working on a PR to when the PR is deployed to production. By improving PR Cycle Time, your engineering team can deliver changes more quickly to your customers.

What Are The Underlying Metrics?

To help in tracking PR Cycle Time, there are five key metrics to use. These are:

WIP (Work-in-Progress) Cycle Time

This is the time taken developing a PR until it is ready for review. Each PR is different, so it’s hard to give concrete advice. However, encouraging smaller and focused reviews and having clear and open lines of communication will reduce a PR’s complexity and reduce development time, as contributors are able to access the information they need much more quickly.

Review Cycle Time

This is the time taken for a PR review to complete. As discussed in other goals, there are a series of ways to reduce this time. You can increase the ratio of reviewers to contributors. You can improve how PRs are organised, prioritised, and labelled. You can prioritise reviews, and encourage small and focused reviews. Consider each of these, and others, regularly as your work to reduce your review cycle time.

Merge Cycle Time

This is the time taken to merge a PR into the mainline code branch. Among other approaches, strongly encourage smaller and more focused PRs so that they can be implemented as quickly as possible. In doing so, the likelihood of a merge conflict with other PRs, that make changes related areas, can result.

Release Cycle Time

This is the time taken to create a release incorporating the PR. No two pieces of software are the same. Some are command line tools. Some are web-based applications. Some are micro services. The list goes on. Regardless, consistently review how your releases are built to see how the process can be refined and made more efficient.

Deploy Cycle Time

This is the time taken to deploy the changes in a PR. There are numerous tools, services, and approaches to deploying modern software. You may use home-grown shell scripts. You may use veteran tooling such as GNU Make, Ant, Rake, or Gradle. You may use more recent tooling such as Containers in tandem with GitHub Actions. Regardless, regularly review your deployment processes to improve them and reduce the time required.

How Do You Accelerate Software Delivery?

Just as with increasing release frequency, we recommend:

Use Continuous Integration (CI) tools. CI tools like Jenkins, GitHub, and Actions let you automate software releases.
Use automated testing. Using automated testing tools, like PHPUnit, JUnit, and Go Test, increases your chance of discovering bugs and regressions early on and enables swifter releases.
Use feature flags. Releases don’t need to contain fully-vetted and signed-off features. However, if you use feature flags, functionality can be tested by a range of users.
Use PRs. Small, focused PRs allow you to add new features, old deprecate functionality, and fixes to existing features so that you can integrate them at a rapid rate.
Have clear lines of communication. Setting up open and transparent communication within a team (and the entire organization) creates an environment where questions can be asked and answered quickly. This allows you to implement functionality if needed rapidly.
Have a clear release schedule. Clearly stating the release cadence clarifies stakeholders, developers, and customers. By doing so, you set up expectations for everyone. ‍
Make code release and feature release independent. Allowing you to quickly deploy code artifacts, thus validating product soundness before activating a feature is critical to reduce risk, thus increase velocity.