The ideal Release Process
Introduction
The release process should transfer the business from ideation and development to operations. It can be a complicated process with many manual steps. It can also involve downtime that is visible to end-users or customers.
The release process is a sensitive area as it is where many issues will surface. The challenge is identifying if the issue is in the project design, the code, or operational requirements. Finger-pointing will never resolve the issues and the notes below are an attempt to address the most common release pain points.
Part 2: Ideal Release Process
Automation should be used whenever possible
Typical candidates are the build, test, release, and deployment phases. In other words, all of them. Code should be stored in a vault or repository that supports automated testing as it is written. This helps keep subsequent steps in the process from getting bogged down with bad code or other issues.
Releases should happen regularly instead of waiting for big feature-packed time bombs.
Adding more features to each release creates more risk, requires more time debugging, and generates unease in staff responsible for the deployment. Not only is the deployment more complicated but writing automated tests for such large scenarios takes proportionately more time. It may even fall back on manually testing or review introducing hours of wasted developer/QA time.
All phases should be tested before release
It seems obvious, but this does not always happen. Code may be tested for bugs and upon finding none is deployed. However, minimal attention was given to the release phase itself where issues are discovered by customers unable to use the service. As mentioned above, the entire stack should be automated to reduce the chance of this happening.
3rd party software should follow a similar process
External software is likely to be updated less frequently but still requires testing. If the new version adds new features, they should be tested if your business plans to use them. If the release adds new back-end integrations, they should be tested for compatibility.
I feel that every software engineer, QA dev, or technical designer I know has experienced at least one of these pain points. :S This article is a good reminder that we can always do better and I appreciated how you outlined what the impact will be to a project should you ignore a step in the process.
Thanks for the article, Malcolm. We see this often in HR systems - the third party provider will do an upgrade without advising in advance or allowing us to test it, and suddenly we can't do any reporting or some functionality fails or people don't get paid, and we have to scramble to get it fixed. Testing is so important, and maintaining frequent or constant communication with customers and end users cannot be stressed enough.