How do you determine when a software release is successful?  Each release is different and different types of software can measure success differently.  There might be errors during deployment that don’t adversly affect customers…was it successful?  A successful release starts with a well designed release plan. 

Software developers and QA personnel don’t typically have permissions to production servers, so there is a hand-off between these teams and the production team.  Without a release plan, the process is full of uncertainty for the release team.  How do I know if it worked?  What if I need to roll back?  Is it normal for the deployment to take this long?

Here are some things that should be included in any release plan: 

• Maintenance window.  It’s highly unlikely that new software can be deployed without an interruption of services.  An understanding of customer patterns will help determine the best time to release new software with the least impact.  Once a maintenance window has been determined, it’s important to communicate this time to customers, QA and the release team.
• Backups.  Before any change to production servers you should ensure that you have backups that are sufficient to restore or rebuild the system.  While this may seem like common sense, this is sometimes taken for granted and thus, forgotten.
• Detailed deployment instructions.  A step-by-step guide to deploying the new software including:
  • The location for all files that are to be deployed.
  • Module dependancies and the order in which these modules should be installed
  • Any services or processes that should be stopped before or restarted after deployment
  • Changes to configuration files
• A roll-back plan.  As much as we’d like to think that every deployment will be successful, it’s a simple fact that some are not.  If we determine that the deployment has failed, what are the detailed instructions for returning the system to a known working state?
• Go / No Go.  If a release is not initially successful, the immediate reaction is to troubleshoot the problem to try salvaging the deployment.  How long do you try to fix the deployment before rolling back to a known good state?  Who can make this decision?  You should have someone on  hand that understands the impact moving forward (increased downtime) as well as the impact of rolling back.
• A way to determine success or failure.  How do we know if the deployment was successful or not?  The release team will need to be able to determine if the release was successful in the event that a representative from QA is not available.

 The percentage of successful releases is a great metric to bring focus to your release plans.  It’s a metric that crosses departmental boundaries and encourages communication and planning prior to a software release.

What do you expect to see in your release plans?

Popularity: unranked