Increase Release Frequency
Why Is It Important?
Regardless of the reason for releasing changes to an application, whether that’s releasing new features, responding to new or existing competitors, fixing security bugs, increasing software performance, improving accessibility, or something else entirely, the more often you can do that, the better your software will be over the course of time.
What KPI Should You Track?
The key KPI to track is Average Release Frequency Per Day. It is only by knowing how many releases are made that you can know if you are releasing at the desired frequency. While you may not release on a daily basis, it helps factor in whether you’re meeting your desired release frequency.
What are the Underlying Metrics?
To help achieve this KPI, there are four key metrics to use:
- Pull Requests created. The greater the number of Pull Requests, the larger a release’s size potentially becomes, and the longer it takes to make. Aim to include as few PRs as possible in a release for the greatest speed.
- Active contributors. The larger the number of active contributors, the quicker PRs can be reviewed and merged into a release. Wherever possible, grow your list of contributors, from junior through to senior developers.
- PRs waiting for release. Aim to keep the waiting PRs to a minimum so that the release is quicker to make, is less demanding on available contributors, and is less complex to make.
- Average release size. The larger a release size, the greater the depth and complexity of the changes it will make. Consequently, the larger a release the harder it is to manage and the more time and care need to be taken before it can be made. Given that, the smaller a release size is, the quicker it can be made.
How Do You Increase Release Frequency?
There are many ways to increase release frequency. Here are five key ones.
- Use Continuous Integration (CI) tools. CI tools, such as GitHub Actions and Jenkins allow software releases to be automated.
- Use automated testing. Using automated testing tools, such as PHPUnit, JUnit, and Go Test, increases the likelihood that bugs and regressions will be discovered early, allowing a release to be made.
- Use feature flags. Releases don’t need to contain fully-vetted and signed-off features yet can still allow for functionality to be tested by a range of users, if feature flags are used.
- Use PRs. Small, focused PRs allow new features to be added, old functionality to be deprecated, and fixes to existing features to be integrated at a rapid rate.
- Have clear lines of communication. Having clear and open communication within a team and more broadly within an organization allows for questions to be asked and rapidly answered, allowing functionality to be rapidly implemented if still required.
- Have a clear release schedule. Clearly stating the release cadence provides clarity for stakeholders, developers, and customers. By doing so, everyone will know what to expect.