A client of mine started out with random ad-hoc releases with frequent regression bugs and moved successfully towards weekly releases. Here are the main points that helped us achieve this.
The Previous Situation
Previously, a developer would finish some feature and mark the issue or ticket as “Done.” But it was usually a mystery when the feature would make it to the next stage, let alone production. This was mildly frustrating because the developer wouldn’t know for sure if the feature worked as desired.
When it was time to deploy to a stage, the project manager would also ask developers which features would be activated when we deployed the product.
And apart from not having a clear view in what was being release when, we also regularly had regression bugs after releasing: things that used to work had stopped working suddenly.
A First Step: Automated Tests
To increase the confidence in our releases and to reduce the chance of regression bugs, I was tasked with writing a suite of automated tests. This gave us a safety net to make changes. The team soon picked up and added more tests.
What’s nice is that we wrote several of them in a language that the project manager could understand and verify.
Having automated tests in place reduced the amount of regression bugs significantly. This increased management’s confidence to perform the next step.
Increasing Release Cadence
We switched to a production release every 3 weeks. Each week, we would move a version of the software up one stage. We have 3 stages (Integration, Staging and Production), so finishing a feature meant it would be in Production 3 weeks later.
Automating Information About The Release
In our project management system, we started tagging our tasks with releases. Whenever a developer finished a task, they would add the tag of the next release.
We can now easily run a query that lists all tasks for the upcoming release. Everything that is done goes in the next release. What isn’t finished will have to wait for the next release.
Monitoring and Automated Alerts
Automated tests will reduce the chances of bugs, but they won’t avoid them altogether. So we set up monitoring to monitor the health of our system. When a certain threshold of errors was exceeded, we would automatically be notified.
This system surfaced some extra bugs and issues that were previously unknown. We wrote tests and fixed the issues.
Increasing Release Speed
We ran with this for some months. Regression bugs have been practically eliminated and with the increased confidence , we have decided to make the release cycle smaller. We now release a feature to Integration and Staging in the same week and to Production the next week.
So far, this is working without issues. While we’re not releasing a finished feature in the same week yet, the systems and practices we’ve set up should allow us to do so in the future.
The post How to Achieve a Weekly (Or Faster) Software Release Cycle appeared first on Red Star IT - Helping Managers Tackle Legacy Code.
Top comments (0)