News, Reviews and Resources for ITSM Professionals.

Release Management How To (Part 3)

Home » Guides » Release Management How To (Part 3)

Following on from our previous posts; here is our final article in the series of how to do Release Management in real life.

Distribution & Installation

Unfortunately actually deploying a Release is not as easy as this:

Releases should be deployed to the live environment in accordance with the existing Release Management policy. For software releases it’s a good idea to use automation where possible as it will lessen the impact on support teams, decrease the time of the release and reduce the likelihood of human error.

If the Release has to be deployed without automation, then the release implementation plan should contain detailed instructions for deployment, resources, timings, escalations and contact details. An example release plan could include the following details:

Example Release Timeline: Commercial Website Deployment

Pre-requisites that must be carried out the day before the release:

(1)   Development must provide the release notes to the Release Manager and all resources on the timeline by 17:00 the day before the release.

(2)   Development must provide the Release Manager with business sign off by 17:00 the day before the release.

(3)   Release Manager must raise a corresponding change record for the release and ensure that it has been approved at the CAB.

Reference Number 1234 – Commercial Website Release – Date
Time Action Resource
10:00 Divert all website traffic to the DR web servers.

**Communication checkpoint to Windows Team ***

Joe Bloggs – Network Team
10:30 Commercial Web amendments for Production web servers Jane Doe -Windows Team
11:30 Testing & Validation

 

**Communication checkpoint to Network resource**

A. N. Other -Web Team
12:00 Divert all traffic to the Production web servers & Stop DR web server traffic.

**Communication checkpoint to Windows Team.

Joe Bloggs – Network Team
12:30 Commercial Web amendments for DR web servers Jane Doe -Windows Team
13:30 Testing & Validation

 

**Communication checkpoint to Network resource**

A. N. Other -Web Team
14:00 Normalise network traffic to all web servers Joe Bloggs – Network Team
14:15 **Communication to Release & Change Management about the release status ** A. N. Other -Web Team

Escalation Point: IT Services Manager, IT Services Senior Manager

Contact details:

Name Desk Number Mobile Number Email Address

Early Life Support

16844834832_5c463af0f5_z

It’s really important to make sure all Releases have the appropriate support in place immediately after implementation. In the words of Rob England at #PINK16 “we need to avoid dead cat syndrome; aka as the Dev guys chucking something over the fence into production and expecting the Ops guys to make it work seamlessly”.

It may be useful to introduce an “intensive care period” whereby extra support resources are available for a period after the Release to ensure that resources are in place to troubleshoot any issues immediately. Floor walkers made up of Service Desk and Support Staff could be used to support users on the morning of the Release. This intensive care period could be tracked via a short daily meeting or conference call and attendees should include:

  • Release Management
  • Change Management
  • Service Desk Management
  • Problem Management
  • Support Representatives
  • Business Representatives

Again, this isn’t about red tape, it’s about making sure everything is as it should be and that any issues are caught early and zapped rather than be allowed to spiral out of control.

A Warranty period could be built into the Release whereby the new functionality is supported by the development team until 2 weeks after the Release has been deployed, providing there are no outstanding Major Incidents or Problems associated with the Release. The Release Management policy should include provision for warranty periods and guidelines for transition into BAU activities.

Review & Close

7175133946_26ef268d47_z

A post implementation review  should be held after each release to track any outstanding actions and to document any lessons learned. Inputs to a post implementation review could include:

  • Incidents associated with the release
  • Problems and Known Errors associated with the release
  • Issues log (if using PRINCE2 as a project methodology to manage the release)
  • Change and Release Management feedback
  • Customer Satisfaction Ratings
  • Customer complaints and compliments

Outputs from the post implementation review will include:

  • Lessons learned log
  • Known Errors and workarounds
  • Confirmation that the CMDB / CMS / ancient spreadsheet that everyone acknowledges as the single source of the truth has been updated appropriately
  • Service improvement suggestions
  • Breaches to SLAs / OLAs / Underpinning Contracts
  • Required amendments to SLAs / OLAs / Underpinning Contracts
  • Updated work instructions

Keeping a lessons learned log to build on previous Releases and to keep a documented audit trail of all learnings, good and bad. The lessons learned log should be reviewed regularly; at least on a quarterly basis and before the implementation of major Releases to ensure past mistakes do not recur (because let’s face it, if we don’t learn from our mistakes thats just embarrassing). A sample lessons learned log could look like the following:

Example of a Lessons Learned Log

Change Number Date Title Issue Lesson Learned
RFC – 1234 Windows Patching – Office X Critical servers unavailable in Office X due to patching failure. Though testing of all Windows server patches prior to deployment into the production environment.

Revise the process as any issues arise or build any more significant improvements into a Service Improvement Plan (SIP).

 

That’s our take on Release Management; what do you think? Let us know in the comments!

 

Disk Image Credit

Early Life Support Image Credit

Review & Close Image Credit

Vawns Murphy

Irish mum of 3. ITIL V2 Manager (red badge) and ITIL V3 Expert (purple badge). SDI Managers certificate. Further qualifications in COBIT, ISO 20000, SAM, PRINCE2 and Microsoft. Author of itSMF UK collateral on Service Transition, Software Asset Management, Problem Management & the "How to do CCRM" book. Reviewer for the Service Transition ITIL 3 2011 publication. When not being pelted with brightly coloured balls in name of ITIL, I am a senior ITSM analyst for Enterprise Opinions.

More Posts

Follow Me:
Twitter




2 Responses to " Release Management How To (Part 3) "

  1. kobel says:

    Great post, very good inspiration together with specific examples. Exactly what I’m trying to implement. Thank you.

  2. iphone se says:

    TheGizmoid
    I have to thank you for the efforts you have put in penning this website.

    I’m hoping to check out the same high-grade blog posts from you later on as well.
    In fact, your creative writing abilities has inspired me to get my own website now 😉