Often we focus on the requirements, construction, and test aspects of software development without perhaps enough regard for the deployment or release efforts. But depending on the nature of your application, these considerations can be as complex as the development itself.
Release management is generally not just a technical effort. It often includes a great deal of collaboration and orchestration. If you have a shrink-wrap product, you might look at multiple release candidates and perhaps an alpha and/or beta program before going full production. This helps involve early adopters and frequent users in the new changes, where they can help with the early issues and also be potential advocates for the new release.
For a web-based product, you want to think about how you move the product into your existing data center with minimal downtime and the best possible customer transition. We like to think our changes are always preferable to the previous release, but too much change can arouse user frustration. If the interfaces remain intact and responsiveness is maintained, there is usually no problem – but anything we can do to otherwise avoid customer issues is probably something to consider.
Of course there is always an internal review of some kind that should have taken place. Is the code stable enough and maintainable? Just as you decided what features made it into the downloadable release, you may also have to meet as a group and discuss what did and did not make it, what work-arounds and training issues might exist, how the product upgrades and installs, and such. You may end up distributing on schedule with the idea that a patch or other updates will be forthcoming shortly. What goes into the release notes? Is support ready? (Perhaps they were included in your test efforts and deployment planning?) Are all the necessary documents for users and support in place? What does the out-of-box experience look like?
For a web application or for internal IT, you will want to consider how the deployment occurs. How well did you verify the application for production use? Did you run suitable load and performance tests to see that there are no concurrency issues or problems in scaling? Are you deploying into shared infrastructure? If so, how isolated is this change? Do you have a rollback plan if the deployment does not go well? How much time will be needed and when do you decide to roll back? Are there any configuration changes, migrations, patches, or other dependencies to take into account? Are there hardware changes or network configuration changes? If you have a tight SLA – is this also time to make other updates? If you had a compressed QA cycle or if there were other established risks, are they documented, understood, and signed off by the business owner and management? Is this a scriptable deployment – or a canned and repeatable one – that can be performed according to a proven procedure… or is it a first-time deployment. Have you abstracted out the environment-specific elements and made sure of the full deployment technique? How do you know your deployment definiton is thorough? When will your next deployment opportunity be if this one is unsuccessful? How will you verify the deployment? Are there any things you can put in place ahead of time? What does the user see while the system is unavailable – is there a downtime message? Have users been informed well ahead, in accordance with existing agreements? If the deployment MUST occur on a certain date, what can you do to remove risk further? Are your deployment people available and well-rested? Do you need any special individuals? How many layers and machines are involved? Can you isolate and verify at key interfaces, to quickly troubleshoot? Are timeouts properly coordinated to fail the system close to the actual problem and yet also provide proper recovery or messaging to users and other interfaces? Is the system secure and will all compliance issues be preoperly addressed?
There are a lot of things you can do to make a deployment or release go well or go poorly. You do not want to be unsure of what you are releasing – so you need to have tracked changes well and established a definitive release. A tight maintenance window is not for problem-solving unless it has to be; ideally the deployment method is tested and well-understood. How easily can you quickly verify and validate what you have deployed? Can you actually design the product for easier deployment and verification? For hot fixes or rolling deployments? Are there ways to deploy with no downtime and no user impact at all?
There are many elements to good release management. But discussion on this topic is limited… So I will endeavor to detail out more considerations, details, and practices in my next post.