At its most general, “releasing software” is the process by which software is delivered from the engineers creating it to its users. This can take such forms as:
All releases are managed in some way, but there's a wide spectrum available for the thoroughness of this management. One extreme would be the software used on an aircraft or space shuttle. The software will be rigorously tested, following a strict process. It will require sign-off from many different people to ensure proper quality metrics and functional requirements have been met. Only after this thorough and well documented process is complete will the software touch the actual hardware in-flight.
By contrast, if you've got a website, you may telnet (or, if you're really fancy, SSH) into your web server, use
nano to open up
index.php, make some changes, and “release” your software by hitting save.
The former process is vital when lives and millions of dollars of equipment are in the balance. However, for run-of-the-mill software projects, such a high overhead would likely be daunting and overly costly. The latter process (if we can even call it that) is just barely sufficient for managing the most amateur of projects, but introduces substantial risk of security holes, downtime, and lost work, which on almost all projects will be unacceptable.
Understanding the trade-offs in release management and the requirements of your project is an important part of designing the release process for your project. As you've likely noticed, the trade-off here is between the cost of high quality versus its benefit. In addition to navigating the overall trade-off, this post will give some advice on tooling and approaches that will reduce the overall cost of good process, making it possible—to some extent—to have your cake and eat it too.
Taking the broadest view, release management is a process that starts at the requirements phase, and lasts until a successful release. As a motivating example, we'll use the case of adding some basic functionality to an existing website. The process looks something like this:
Define the requirements for the upcoming release. In our example: add a visitor counter to the homepage (we're going retro). The visitor counter must work on both desktop browsers and mobile devices.
State some concrete acceptance criterion. This will be testable assertions based on the requirements. This may be in the form of automated test cases (perhaps using Selenium for our example), or a manual test script to be run through. It would include details like:
Deployments are made to a staging server. Such deployments can be triggered by pushes to a special branch or manual intervention. The goals should be:
Quality Assurance (QA) reviews the staging environment to see if it meets the acceptance criteria. QA should not only be testing the new features, but also all old features as well to avoid regressions. Once again, automated is better than manual, but some manual testing may be necessary. Make sure you're not just performing success tests, but include failure tests, randomized tests, and much more in your test scripts.
After proper sign-off from QA, deploy the new software to production. Once again, devops comes into play, and an ideal deployment will include these ideas.
As you can see from these steps, we're defining release management to be a broad role. The release management objectives in this sense are to ensure that the code that ends up being released to users properly implements the new requirements, without introducing new regressions. This is a process that encompasses devops, QA, and software development. Importantly:
No one team can be singularly responsible for a successful release
You may (rightfully) point out that not all of the steps above are present in the release management of a lot of software in the world. What I'm describing is a minimal set of steps that maximize the benefit of a process while minimizing its costs, for projects of common size and common quality requirements. If you're throwing together a static homepage and don't care if the layout sometimes breaks: this process is likely overkill. If you're NASA, it's far too little.
You may have noticed that development is conspicuously missing from the process above. In practice, it occurs between steps 2 and 3 above. I've left it out of this list, however, as it's not truly part of release management. The development process is external to release management and provides it input (source code to build/test/deploy), in much the same way as business decision activities are external to release management, only interacting with the process by ultimately defining clear requirements.
Some roles naturally fall out of the steps listed above.
The process above leads to some natural best practices.
There are many tools out there to help with all of the above. Here are some of our favorite at FP Complete, which we use regularly to help our customers bring their projects to completion:
If you'd like to learn more about any of these topics, FP Complete offers training and support on a wide range of devops and software development topics.