Posted: Tue Mar 04, 2008 7:28 am Post subject: Bug Fixes - Change Management?
I'm unsure what ITIL best practice says here, but I'm looking for some feedback/suggestions.
Should every application bug fix be pushed through Change Management or addressed as an incident?
* The fix is to a service in production
* The code is well tested before being pushed to production
* The number of bug fixes weekly are quite large
How do others handle this? Do you handle the scenarios as emergency change requests? Do you submit a weekly bug fix list to CAB for approval? Do you handle them simply as Incidents to correct the application without submitting to CAB?
Joined: Feb 28, 2006 Posts: 411 Location: Coventry, England
Posted: Tue Mar 04, 2008 5:52 pm Post subject:
The basic answer to your initial question is 'Yes'
All bug fixes imply a broken application, and therefore a loss of service to the user. This requires a SD ticket to be raised, and then a Request For Change needs to be raised to correct each fault.
There might be a case for raising a 'collective' RFC, but this is not usual in my company. The only circumstance that would allow this, would be if all the faults are repeats of the same fault. e.g. a router keeps failing on a specific network path, meaning a replacement is required.
I would not expect to cover bug fixes with a Standard Change, unless the requirement to cure the fault(s) was a hardware swap out. Code problems within an app are not covered by a Standard Change
All Changes should be well-tested before being put anywhere near Production, so this statement puzzles me!
Are you referring to the cut-down testing that moght be allowed for an emergency change? Even this testing should be as complete as is possible given the compressed time frame.
I hope this has been of some help _________________ Regards
Incident raised for the service problem experienced, bug identified and either RFC raised on the back of the incident if the fix is available, or the incident goes to a problem and the RFC is raised on the back of that when the fix gets built.
Thank you all for your replies. Come to find out, majority of what they were lumping into the category of bugs were really escalated requests or enhancements to applications...not broken code. Again, thank you!
Sorry to be chiming in late on this but I was taught by an instructor from a company with a colorful pachyderm that a break/fix only went through Change Management if the resolution modified the CI.
If the resolution is simply restoring the CI to the approved baseline (whether swapping out like-to-like hardware or re-installing the baseline code) that this was not documented as a change. Only if the resolution actually changed the CI (different router or switch, or modifying code from baseline) would documentation be required.
Now I'm not saying anyone is wrong... and this training was 4 years ago... but has the documentation of break/fix always been considered to go through Change or is this up to interpretation?
Joined: Sep 16, 2006 Posts: 3407 Location: London, UK
Posted: Tue Mar 25, 2008 10:09 pm Post subject:
The important thing here is for break/fix or change is the urgency of the break / fix.
and be pragmatic
If your incident tool links to your cmdb and the CI being 'unbroke / fixed' is tracked in the incident and the incident includes the fact that there is no service, then i would just use the incident to track the break/fix and h/w swap
if the incident that is break / fix and there is currently no outage and the solution to the incident is to replace h/w and incur downtime, track it in change management
the reason is that usually SLAs are sometimes written that approved changes that incur down time do not count against any availability stats or such like.
Our maintenance windows were exempt from the % availability
As to software bug fixes, i always recommend changes to manage this
but first i always insisted that the software team does a build / test in the dev world first
if this can not be done, when the change is raised, it should say so explicitly
And if the s/w bug fixes are tracked via both change and incidents, this should highlight to management that there is something wrong with the application _________________ John Hardesty
ITSM Manager's Certificate (Red Badge)
Change Management is POWER & CONTROL. /....evil laughter
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum