Production Release – The D-Day

ProductionRelease

Here I am trying to share some of my thought processes that can help a team or an individual to strategize for a better release day. Few of the points might be similar to you and few might not be the ideal case involved in a release process. The points highlighted are all generic to thought processes that can make Production releases efficient and effective. Production release happens based on sole criteria specified by organization either during a day or during night, mostly it is termed as release night. It is a Judgement Day for all the developers like us since this is the day when all our codebase, fixes becomes live to world and any bug associated with the codebase might create a big impact once the functionality is live to customers.

Few issues that might be encountered:

  • Update of a DB Script failed in Production Server.
  • Compilation of a library missing to be part of the release
  • HTTP 500 Server error occurred during the release time
  • Target Framework is not installed in the Production Server
  • Ports and IP Addresses not configured or open to access the websites and web services hosted in Production Server

With few of the examples that I had shared RCA or Root Cause Analysis are followed after the Release Night. This is strongly practiced as a best practices in organizational level to adapt best ways to strengthen the release processes.

I feel few follow up action items that can be a good practice a day prior to our deployment day will make the release smooth and flawless. Also some of these action items might not be the ideal approaches and varies from organization or project level practices.

  • Pre-deployment instruction set should be created prior to deployment day and provided to deployment team in order to avoid any discrepancies during deployment day
  • Initiate a deployment check guidelines with cross teams and dependencies prior to deployment day
  • Verify the Production source code branch in order to have a checkpoint of the latest codebase being migrated
  • Prioritize your regression testing having all test cases covered including compliance and data level testing
  • Initiate a process prior to release date with Software Configuration Management team or Deployment team to validate the environment, IIS version and Application Pool configuration, COM Component and necessary 3rd part library configuration in the Production Environment
  • Consider creation of checklist point for dependency teams like Environment, DBA, Cross teams, etc., and contact persons prior to release date for conference call as and when required
  • Have your Mock data prepared for various services to be tested once the deployment is completed with latest source code using WCF Client, WCF Storm or SOAP Client.
  • Create checklist for all the DB objects that is required to be validated during deployment phase along with SQL statements to identify the objects changed, or global data transaction happened.
  • Validate with Network team for all IP addresses, Ports that are required to be open and configured, F5 and firewall configuration defined and standing instructions for remove discrepancies.
  • I feel we should not consider the performance enhancement or issues during the release period and keep this as a separate enhancement or issue to be provided as hotfix release later.
  • Keep all the communication channels like Team Communicator open as separate window, Conference Bridge Call open for immediate attention during crisis period, etc.

At last and not least please don’t PANIC ….this will never help you and your team. So you can see that taking few approaches during release night can make your Production release more efficient and effective.

Leave a Reply

%d bloggers like this: