Blog

When done isn’t finished

Your code is complete, you’ve fixed that bug, built a new feature or done some much needed refactoring. You’re done. Except done is often nowhere near finished.

Your code is complete, you’ve fixed that bug, built a new feature or done some much needed refactoring. You’re done. Except done is often nowhere near finished.

There’s still a painful number of manual steps that every tech team needs to complete before release, whether they work in a start-up or a big bank. The more controlled the industry the more hurdles you’ll need to clear before your work sees the light of day.

We’ve all lived it, the code reviews, QA testing, sign-offs from product and design, release planning, and release comms. Then if you’re in a regulated industry go ahead and add manager sign-off, completing change control, ops review and perhaps throw in a full CAB review for good measure.

In even the most efficient startups these steps can add hours to every release. In a bank they frequently add months. These reviews require an accurate record of what’s been created, tested, reviewed and approved. Developers may see git as the source of truth for this record, but it’s rarely in a format anyone else wants to see or understands. So we add the step of creating a decent release note every time we ship.

Release notes are frequently written manually in word docs or a tool like Jira, where each ticket is moved from the ‘Done’ column into a release note. Of course, this assumes the happy path where all tickets were added, updated and in the right place at the right time….and no engineers got sidetracked working on something without a ticket or no task changed scope drastically part way through.

Often boring but always important, release notes ensure that companies meet regulations and their own quality standards. Not only that, release notes provide the information marketing needs to promote the new feature. If customers don’t know what you’ve built then they won’t benefit from or use it.

Release notes are just a small part of the challenge faced by tech teams when releasing code but it illustrates the inefficiencies that can come out of manual release processes. These challenges don’t just limit productivity but increase the risk of missing appropriate approvals or reviews, especially when they’re repetitive, boring and stop you doing what you’re best at — coding. We automate because it’s repeatable, objective and provable but automation hasn’t impacted the release process in any meaningful way…yet.

By automating the release process and having a codified tool we can reduce errors, improve quality and increase release speed and control. You can’t add value to the product and for the customer without jumping through at least some of the release management hoops, especially if you work in a regulated environment.


Subscribe to our newsletter!

Michelle Arnold

About the author

Automate your release process. Faster than what you're currently trying.

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
Automate your release process in a few clicks