Continuous Delivery of the CHT

If you’ve been paying attention, you may have noticed CHT Core Framework releases are happening more and more often lately. This isn’t just your imagination! As shown in the graph below the days between releases has been trending downwards over the last 5 years.

image

This has been a deliberate initiative in order to get fixes, improvements, and features released and ready for installation as soon as possible after the change has been developed. This means if there’s a change a project needs then it can be rolled out into production quickly, reducing delays waiting for the release to be scheduled.

In order to achieve this safely, several improvements have been made to the process.

  1. The Continuous Integration process now automatically executes 100% of tests that used to require human execution.
  2. Static analysis tools like SonarQube and eslint have been introduced and extended to find bugs before release.
  3. The release process itself has been streamlined to reduce the time it takes to publish the version.

The ultimate goal

The quicker improvements can go from finished to being able to be installed the better. The shortest possible time is possible through a process called Continuous Delivery whereby as soon as code is merged to the main branch, it is built, tested, and immediately released with no human involvement at all. The steps where humans are still involved, such as Code Reviews and testing, are done before the code is merged, so once those pass there is nothing blocking the release. This means there could be a new version published every day, most of which won’t be of interest to most projects, but if it’s a fix blocking your project then you’ll be able to update the same day as the patch is merged.

This is particularly important as there are now more community contributions than ever. Fully automating the release removes the release gatekeeper, giving the community more control.

Continuous Delivery has been running for a few years for cht-conf releases, which is a useful example for how this works in practice. Not only have improvements been available for installation more promptly, releasing requires no effort, and because it follows the same steps every time there haven’t been any mistakes during the process.

There is still some work to do before turning on Continuous Delivery for CHT Core Framework.

  • Completely automate release notes generation and publication.
  • Improving the release notes so instead of having to read each one on a separate page the reader can see an aggregate of changes between two releases.
  • Provide a better solution for labelling known issues.

The policy for supported versions will also have to be updated to be compatible with very frequent releases because the current three month support would mean backporting fixes to dozens of minor versions which would be complicated and error prone. If it’s extremely easy to get a new release published and installed, then does it make sense to only fix the bug in the latest release?

More detail on these steps is covered in this GitHub issue.

What do you think? Would this make it more likely for you to contribute software? How would this impact systems administrators? Do you have any questions?

9 Likes