Why should you release software at a regular cadence?
One of the good habits that I try to encourage my team, is to release software at a regular cadence. There are reasons for this. With waterfall process, we release software once a year or YEARS, and our feedback cycle length is extremely long and costly. With such a long feedback loop, it’s painful for the users to deal with resident bugs and it’s painful for developers to remember and resolve ancient bugs that they wrote 1 to 5 years ago. In terms of economics, as we find bugs that escaped into production, it becomes exponentially expensive to fix them. As a result, practices like Paired Programming, Continuous Integration, Test Driven Development, and others, have really increase our chances to catch and address bugs quickly and earlier in the feedback cycle.
With the DevOps process, it’s really easy for us to get deep into the development phase, so much, that we often hesitate sometimes to release regularly. We become fearful that this batch of production code isn’t ready or it needs more features to provide user value. I’m here to tell you, ANY push to production, whether it is a patch or minor release, is providing user value and we’re essentially reseting the incremental bug cost every time we push out a bug fix. In addition, we are also shortening the length of feedback cycle so that we can conduct user interviews, get feedback on our released features, and continue to strive towards building an application that users call it a JOY to use.
Again, there’s NOTHING stopping your team from releasing a patch on the same day at 2 pm and releasing again at 4 pm. That’s the beauty of DevOps. (Here, I’m assuming you’re working in a DevOps environment where teams are empowered to be autonomous and release as often as they like.)
If you are doing TDD, refactoring, and paired programming, please strive to increase your confidence in tests and release process. If you are highly confident in your test suites, then you will be able to push out a new release at ANY TIME. In addition, if your release process is quick and easy, developers would not mind pushing often.
Most importantly, your release cadence is your product team’s brand. The fact that your users can count on a new release, say — every Monday, increases their confidence and trust in your product and team.
Now, if your release process takes more than 3–5 steps, you need to find ways to automate or simplify it. One of the things that can discourage developers from doing software releases is the complexity in the release process. At this time, our team has a release process that has more than 10 steps for our 4 micro-services.
As a result, no one on our team is currently eager to do a software release — even though it meant that our users would get a better version of our application.
Majority of the release process is automated by the Concourse pipelines, but there are still manual processes like updating a release doc or triggering a release. Our current goal is to simplify our release process down to a “one push” button so that any developer, especially our junior members, can do a release without fear that something would break. Once you get the team into a habit of releasing on a certain day or time, it should just be like clockwork.
Join our community Slack and read our weekly Faun topics ⬇
