The traditional software release life cycle is a bit outdated, not to mention difficult to share and talk about with the business and other non-technical users.
We’ve adopted a simple cycle to discuss internally where our web applications are in their release life cycle. Once the app is launched to real users, it’s as simple as ABCD.
Development
The first and most obvious phase. The developers are working. Leave them alone.
Pre-Alpha
At this point the application is being tested internally by developers and QA engineers alike. The app is not ready for real users yet, but the business should be thinking about which users should be testing first.
The support staff does not have an active role in this phase, but should start to get trained up on the new system and how they’re going to handle the customers once the product is ready for alpha testing.
Alpha
A very small subset of users are chosen to test out the product. The users as well as the support staff must be aware that it is the expectation there will be bugs during this phase. Plenty of them.
We use this phase to fix any issues that were unforeseen during QA. Customers have weird data. They do things differently than we ever could have imagined.
All hands must be on deck for this phase. Issues that arise during the alpha period are of the highest priority. Everyone must work together to ensure as smooth of an experience as possible for the customer, but in this stage building the product is a higher priority than the customer’s experience.
Beta
Once the small subset of users have been running smoothly for a couple of weeks or so, we enter the beta period. At this point we bring in about 10 times the users as we had in alpha. While alpha may have only had 4 users, beta has 40.
The main purpose of this stage is to begin testing scalability. There’s also another paradigm shift and that is that now the customer experience is more important than the building of the product. We’ll happily shut off the system in alpha stage if it can help the app in some way. Not in beta.
The customer and support team should still expect bugs in this phase, but at a much lower rate, and still with an enhanced turnaround time.
Candidate
We’ve officially exited beta. At this point we can start bringing any and everyone onto the system. This phase is all about scalability and monitoring.
We’ll be monitoring the system under intense load and ensure that it is ready for customers for years to come.
We may start adding some small new features during this phase, and may even switch focus onto another product while the system is running. Bugs that come in will have a medium priority and may have a slightly slower turnaround time than before.
Dependable
The line between the Candidate and Dependable version is the finest of the cycle. It all depends on how quickly customers are entering the Candidate version and how well it’s scaling. Ideally, we can easily scale as we bring on more users and we can switch to the Dependable phase pretty quickly.
I prefer to stay in the Candidate phase for a bit longer, just to ensure we’ve covered all our bases.
The main difference between Candidate and Dependable is the Dependable version should now be marketed and advertised. It’s ready to go. Web apps are never finished, but now it has entered a state where it should be self-sufficient and monitored.
Conclusion
This is certainly only a high-level overview of the SRLC, as there are plenty of other release concepts intertwined in the phases such as A/B testing, account flagging, etc.
The traditional software release cycle has origins dating all the way back to the 1950s at IBM. It has since been adopted and adapted by numerous companies for numerous types of products.
Our release cycle doesn’t deviate too much from the concepts that have been in software for decades, but it makes it much easier for the whole business to get on board and be able to communicate the state of a web app that’s ready to be released.
