Software release days are big occasions. The code has made its way through coding & testing and is finally ready for prime-time. It is time to make sure you have lots of documentation. How do your various types of users do their work? In a system as complex as utilization review, each workflow within the software could be an entire book of instructions. Your job is to figure out how to reduce it down so that it’s easy to understand but still comprehensive enough to answer your user’s questions.
If this is your first release, most of your work is going to be manual. There is hardware to set up, supporting systems to license and configure, and a multitude of tasks to complete. Be sure you have competent IT people who understand your goals and can support your software development team. You will be storing Protected Health Information as part of your utilization review software system, so you’ll need to ensure you have top-notch security and encryption. If your application is web-based, your IT team will set up your web servers, data servers and firewalls. You may already have most of the necessary hardware, and it’s tempting to put it to dual-use to support your new software, but don’t fall into that trap. Keep your utilization review system isolated to protected it from threats (both inside and out).
A release usually starts with locking down the code to stabilize it. Typically, multiple servers are set up, called “environments.” The first environment is your developer’s workstation – this is where they do their primary coding and unit testing. Once the software is ready for testing, the coders merge their changes into a testing environment, where the testers can get to it and start doing their own unit testing and initial integration testing. As code passes testing and is approved for the release, it is merged to a staging environment. This is the last stop before being released. At some point before release, this environment must be ‘frozen’ – no more changes are allowed to it until after the release. This allows your testing team to make sure they’ve found all problems and allows your documentation team to have something solid and stable to document.
The amount of time between the freeze and the release varies. If this is your first release, you’re probably going to allow for 2-3 months of testing. At this point you should also be testing all your end-to-end workflows and documenting them for future regression testing. If it’s only been one to three months since your last release, a freeze period of a couple weeks may suffice. Gauge the mood and confidence of your testing team. They are the best barometer for determining how much release testing you need. Once you are confident in the application’s stability, it’s time to release. Releasing a web application for the first time is usually just a matter of opening up the firewall to allow the rest of the world in. In subsequent releases, you’ll need a good plan for rolling out a new version with minimal disruption to your existing users.
You’re live! Time to take a minute and congratulate your team (and yourself) for this impressive milestone before thinking “What’s next?” You’ve probably got a list of things that:
1. Didn’t finish coding, passed testing or got approved for the release before the freeze
2. Never made it off the drawing board in planning and design stage
3. Were thought about too late to get started on during this release cycle
4. Your users need but didn’t even think about
Now is the time to evaluate all these items, decide what you want to do for the next release, prioritize and start planning your next cycle. Then, it’s back to step one, reevaluating all your previous assumptions to make sure they’re still current.
Thanks for joining me on this high level view of the software development world. I’ve deliberately skipped over many important things for the sake of brevity, especially in the areas of design and automation. There are entire books written on most of the subjects that I’ve touched on, and I encourage you to explore areas that interest you.