August 2, 2007 at 1:59 am #2224844
ITIL – Change & Release ManagementLocked
by vawns · about 15 years, 4 months ago
I?m looking at making some improvements in my current Change Management process and part of this will review the relationship with Release Management and specifically what constitutes a Change versus what constitutes a Release.
I would love to know how other organisations make the differentiation, how do you decide what?s a change and what?s a release and how do you manage the relationship between the two.
Any help or feedback would be gratefully received 🙂
Many thanks & best regards,
VawnsThis conversation is currently closed to new comments.
August 2, 2007 at 2:30 am #2635285
ITIL Change <=> Release Mngmnt
by rob mekel · about 15 years, 4 months ago
In reply to ITIL – Change & Release Management
Any Change made will result in a change in the CMDB. There for will effect your release mngmnt
As I read your question it comes to mind that the issue you are referring to is more related to Update versus Upgrade or Patch versus Release. As you say “what constitutes a Change versus what constitutes a Release”
As Changemngmnt has to do with the way you choze to get the changes trough to your organisation / to put them in effect or NOT.
As Releasemngmnt holds the results of what is the current state. The desicion made on whether or not to go through with a certain change is made in the Changemngmnt proces not in/by the Releasemngmnt proces.
Changemngmnt therefor is leading Releasemngmnt is the follower even if Releasemngmnt has an issue with certain soft- or hardware it has to follow the route of ITIL to get a OK from Changemngmnt to put it into effect.
September 18, 2007 at 3:07 pm #2513553
More control and less ITIL?
by miquel gantzer · about 15 years, 2 months ago
In reply to ITIL Change <=> Release Mngmnt
Rob’s comments make a lot of sense, although the initial post probably suggests that the processes in place are not as ITILized as they could. Change Management is all about assessing and deciding which Changes will be implemented in the managed systems. Release management might focus on how these changes are going to be grouped (if needed), published, moved into the production environment, or whatever is the right approach depending on the type of system being managed.
What was probably missing in the initial scenario was some type of CMDB. The Configuration Management Database might allow you to record what changes were suggested, why, when, by whom, and whether they were approved or not (even why that decision was taken). And then in which release (as in when) they were made available. Depending on the complexity of the system maintained, this can be something as easy as a Spreadsheet, or something as ‘terrifying’ as a commercial CMDB from some vendor of ITIL-flavoured suites.
January 26, 2009 at 8:54 pm #2776425
January 24, 2008 at 8:31 am #2665390
Relationship between Change and Release Management
by itsm consultant · about 14 years, 10 months ago
In reply to ITIL – Change & Release Management
It looks like you’ve already gotten some good advice from a few people to get you started.
It is theoretically correct that all changes should result in a update to the CMDB (either to the CI itself or to the attribute of the CI). This depends largely on the level of granularity (detail)captured in the CMDB.
Initially, the CMDB is more like than not, to be rather limited in scope and detail. Thus, most changes made will be to the attributes of CIs rather than to the CI itself.
An example: A change to a database table will probably be captured as a modification to the Server, Application or System rather than to the database instance itself.
Over time, it may become necessary to promote the database instance to CI status and begin to record changes against it.
Further, not all changes result in Releases. The scope of Release Management is very specific and is limited to modifications to Software (can also include related Hardware documentation necessary to effect SW change) components.
The scope of Change Management is much broader. Its includes all changes to which may potentially have an impact on the IT Service. This can include changes from batch job scheduling, access priveleges, performance testing and hardware moves to VPN configuration changes and beyond.
In my experience, it is very important to clearly establish the differences between these processes from the beginning. Failure to do so is likely to cause confusion and duplication of effort.
Additionally, it is also important to distinguish the differences between Release Management and Project Management.
Just as not all changes result in releases, not all projects result in release. Release Management should establish the policy for moving Software (and related HW and documentation) from development to production. This includes creating the Release Plan which defines the requirements for testing, acceptance, training, support and deployment.
Good luck. Please feel free to contact me directly with any other questions you have.
Also, check out my blog at:
December 12, 2008 at 2:01 pm #2972309
About change and release management
by adydashora · about 13 years, 11 months ago
Today I got information that, now a days, organizations are breaking off the change and release management. I had an impression that, change and release management are implemented together.
Please help me to understand the processes of change and release management.
December 30, 2009 at 8:23 pm #2820875
Should all change mean a change in CMDB?
by bamitabh · about 12 years, 11 months ago
I have a lingering doubt on whether all ‘changes’ formalized through RFCs imply necessarily a change to the CI or its attributes.Suppose a change affets some not-so-important attribute of a CI, which is not tracked by CMDB. Should that change be formalized as a change and an RFC be raised for that? In the context of ITIL how relevant this change is? Should that be recorded as a change? The IT auditors whould vehemently argue that this change should be recorded and formalized through an RFC.As an application analyst I would disagree. Any opininion or debate on this may be interesting.