What's a Release?

We define releases like this:

• Major Releases, also known as "upgrades," are signified by a change in the first part of the version number, or in the first decimal place of the version number (e.g. version 5.0 to 5.5). These releases contain major feature enhancements including new functions and performance enhancements.
• Maintenance Releases, also known as "point releases" or "updates," are signified by a change in the second part of the version number (e.g. version 5.0 to 5.01). Maintenance Releases contain mostly bug fixes and may also have new functions and other smaller enhancements.

Process

To bring a Release to market, we need to stop coding and kick off the QA/Test/Release process. The idea is pretty simple, in that we promote a block of code in the hopes that it will pass QA and become an official release. While the code is being QA'd, the bulk of the team is working on the next iteration. If critical bugs are discovered in the Release Candidate, then we carefully (with surgical precision) fix just that bug using techniques described in Branch Development. The idea is to disturb as little of the code as possible when fixing the Release branch. The reason being, that the more code you disturb, the greater the possibility for unintended side-effects and the need to re-test.

• In very tight loops (weekly for example), we prepare a release "candidate"
  • We place it up on TEST, and give it a thorough round of complete testing
  • We collectively think this build has the features, bug fixes, and accumulated "stability" to go to market
• We decide to release to PROD when we feel comfortable that we have tested a "release candidate" build enough.
• What is enough?
  • Well, it has to do with balancing risk.
  • For the first release, we will risk exposing the app to a handful of "beta" users.
  • You may also consider the need to test your promotion process, going from TEST-->PROD
• What if we find a new bug?
  • We will branch the code for this Release Candidate
  • We can make code changes to the branch
  • We can do builds from the branch, incorporating just a handful of code changes back into the Release Candidate on TEST
    

Diagrammatically, the process looks something like this:

Overview

As QA/Testers give it a once-over, we should be able to do the following process:

• Review findings with the business on a daily basis – say a 4pm call with the stakeholders
• If any findings are critical, we discuss if we need to add bug fixes to the build or not
• Go Live decision is based on:
  • Is everyone ready?
  • Are the known issues tolerable?
  • Have we done enough functional test coverage to be comfortable?
  • Have we done enough "other" tests to be comfortable? This applies to certain types of systems, where you may have a series of comparative tests you can make. Comparing the application outcome to a golden standard, or a 3rd-party system of record.
    
  • User Manual/Training updated if needed?

So, the process is firm, but the outcome will be evidence-based and subjective based on our collective talented people meeting to discuss.