Posted by: Jeff Timmins | June 30, 2017

Foundations of Release Management

Goals, Success & Details that every Release process should include


The purpose of the following information is to provide the reader with a better understanding of the motivations and thoughts behind my general Release Management process. With different cultures and histories behind the Development groups around the world, a process that works for one team may not work for another (i.e. one size doesn’t fit all).

In addition I firmly believe that the Release Management process should not be forced on a Development group but should be tailored or fitted to enhance the model that the team provides.

Because of these beliefs I felt it important to share what I call the Foundations of Release Management, a common fabric that to be used for each set of custom designed Release Processes.      

Goals for Release Management

  1. Help Development groups get their changes to Production efficiently and successfully
  2. Ensure controlled, systematic and documented Software Releases
  3. Use readiness checklists based on agreed to standards instead of emotion based Go/No-Go meetings
  4. Communicate details related to Releases so everyone who needs to know is informed
  5. As needed function as a liaison between Development Groups and Operations, Governance, Help Desk & others

What is Success for Release Management

  1. Work with all individuals gracefully and in a respectful manner because everyone is an Internal Customer
  2. Production deployments meet compliance requirements set by Governance
  3. Releases deployed to Production in a timely manner without the need for rollback or causing customer impact (i.e. Production deployment should Do No Harm or Production environment should be as stable or more stable than before the change)
  4. Communicate the right amount of Release related information to the right people at the right time so they can be successful in their roles (i.e. No Surprises)
  5. Limited or no Post-Release issues found in Production

The common fabric of all Release Management Processes

  1. Introductory planning with Development groups (one-time tasks)
    1. Team make-up
      1. Waterfall, Kanban or Agile
      2. Desired Production Release schedule
      3. Review Tools to be used by Development groups, standards for change tickets, source control and Code repository for builds
      4. What to expect for versioning of packages & Releases
    2. Environments
      1. Confirm which environments to be used for Non-Production, Production, Training & DR
      2. Confirm management of deployment schedules for last Non-Production environment (considered Staging), Production, DR and Training
    3. Validations
      1. Confirm validation teams for each Environment, including agreement on usage of non-Development groups
      2. If possible, establish standard validation times and validation processes for each Environment
      3. Establish Release Gates for critical environments (typically covering pre-Stage, Staging & Production), see below for more details
    4. Communication
      1. Main Development group member(s) that Release Management should communicate with
      2. Establish Communication Group that works for particular Application. This could include any combination of Business Owners, Stakeholders, Development group, Help Desk or Internal User group.
      3. Establish information portal to be used for Release Management information
    5. Monitoring & Reporting tools
      1. Understand what is currently Monitored & what type of monitoring available (typically made available via Operations Group, used to confirm Release success & acceptable Deployment windows)
      2. Understand available Alerting (used to confirm Release success) 
    6. Document above agreements
  2. Desired Development group activities participation (in order to collect needed Release information)
    1. Scrum ceremonies as makes sense (as a Chicken)
    2. Scrum of Scrum meetings
    3. WaterFall planning and other update/planning meetings
  3. Release related Communication
    1. Weekly update of upcoming/future deployments to Application Communication Group
    2. Help with communication related to unplanned events or issues
    3. Confirm deployment impact notification is communicated to customers
    4. For deployments – specific notifications related for Application Communication Group
      1. Deployment coming soon
      2. Deployment started
      3. (as applies) Issue with Deployment
      4. Deployment complete
    5. Post-Deployment report providing details of success or failover of the deployment
  4. Release Planning
    1. Regularly scheduled meeting with Development group, providing opportunity:
      1. For Development group to request future deployments not yet known by RM
      2. To review to-do items for already scheduled deployments
      3. To review lessons learned from previous Releases
    2. Documentation of Release details
      1. Key dates for each Release added to a shared Calendar
      2. Add details for each Release to Release information portal
    3. Production Deployment window planning
      1. Analyzing customer impact for each deployment
      2. Creating estimated deploy window timing
      3. Identify which team members need to be involved in Production deployment (see Appendix below for examples)
    4. Leading Development group & Ops deployment planning meetings
    5. Managing Change tickets for environments that RM manages schedule
      1. Create Change ticket 
      2. Requesting needed approval(s) outside of Governance
      3. Requesting approval for Change ticket in a timely manner (i.e. within Governance requirements)
      4. Representing Change ticket at weekly Governance (i.e. CAB or Change Advisory Board) meeting
  5. Managing Release Gates
    1. The output of the Release Gates is a checklist to be used by the Development groups to identify the status or completion of a stage of the Release (i.e. Release is ready to proceed to next environment)
    2. RM tasks during testing in environment before Staging
      1. Identify Release ticket for Release
      2. Confirm Staging in and out schedules as well as Feature Freeze & Code Freeze schedules
      3. Confirm Directions for deployment are available and reviewed by Development group & Operations and request updates as needed
    3. Development group tasks to complete before Release packages deployed to Staging
      1. Confirm Directions for deployment are finalized
      2. Confirm list of change tickets for the Release are linked/associated to the Release ticket
      3. All change tickets and their related sub tasks are compliant and closed
      4. All agreed to Code Testing has passed to agreed to standards (e.g. X% passed, no Sev2/Pri2 or higher bugs introduced)
      5. All agreed to Performance & Security Testing has passed to agreed to standards
      6. If applies, packages are moved to shared Code repository for deployment needs & future reference   
      7. Verify/Confirm contents of build – verify or confirm the code build/package includes all changes expected in the Release (i.e. all code commits from tickets linked to Release ticket are included in the build)
    4. RM tasks before entering Staging environment
      1. Creates Non-Production Change ticket
      2. Creates Draft version of Production Change ticket
    5. Development group tasks to complete before Release packages deployed to Production
      1. List of Known Issues of the Release provided
      2. Rollback procedure has been validated (can be done in Staging or before)
      3. All agreed to Code Testing has passed to agreed to standards (e.g. X% passed, no Sev2/Pri2 or higher bugs introduced)
      4. All agreed to Performance & Security Testing has passed to agreed to standards
    6. RM tasks before entering Production environment
      1. Confirm Code repository is locked down to eliminate additional modification to Release packages
      2. Confirms Production Change ticket is approved
    7. Confirming health and stability Post-Release
      1. Monitor Post-Release Incidents created, identify which are caused by my recent change
      2. Be aware of site impacting issues related to the Solution, typically by having visibility to health checks and/or system monitors & alerts.  
    8. Continually reviewing the Release Gates with Quality teams and Environment team on for possible improvements
  6. Managing Production Deployment window
    1. Create meeting invite before deployment
    2. Lead the deployment call, confirm starting & stopping times of various tasks and status during the deployment window
    3. Confirms Change is completed and dismisses the team
    4. As needed, schedule Post-deployment meeting & documentation
      1. Retrospective of deployment
      2. Update post-deployment details document
      3. Update information portal


  1. List of possible groups that would be part of the Production deployment window
    1. Development group members
    2. Operation team members
    3. Validation team members
    4. Support team members
    5. Product Owners, Business Owners and any other group of people that need to be invited (note that providing optional invites is helpful for some people for extra awareness of the deployment)


  1. […] writing Foundations of RM I found that it doesn’t really answer the question of “Why we do or need Release Release […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s


%d bloggers like this: