Changing Version of Software CIs

[dsemeniuk]

This question crosses change and configuration management.

If you have a Software CI defined in your CMDB, say xyz Version 1.0, and you want to make a change to software xyz 1.0 what process/flow do you follow?

Example:

1. RFC is submitted to change xyz due to a defect. Do you link the RFC to the CI xyz 1.0?

2. When do you enter the new CI xyz, say version 1.1 into the CMDB?

3. Is the new Software CI linked to the RFC as well?

Can someone walk through their process in this example?

Thanks.

[UKVIKING]

If the CI is being changed then a change management process is required

You are talking more about tools than the process

It would depend on how the tool is written on whether to link the CI to the RFC

If you have no tool, how will you link.

The process like in the ITIL books
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter

[dsemeniuk]

Hi John, I am not trying to be tool specific but more process.

I am wanting to know as to when someone would enter the new CI Software Version, at what point in the change management and config process.

You have xyz 1.0 running, and then you require to make some changes due to some defects. These changes get approved to be built. Is at this time time you enter the new CI xyz 1.1 into the CMDB as say a planned status or development?

How do you track its status through testing and staging and keep the relationships it has as to where it is installed in those environments?

[UKVIKING]

dsemeniuk,

It depends on the depth/design of the CMDB to be honest.

If the CMDB tracks the application - call it DaWinApp - as a CI, there would be an instance of the CI for Production, UAT, Development version which all would have descending version numbers

Production version being the highest

This also pre-supposes that you use a form of change mgmt for the build and testing into the dev as well as form for the UAT

It will not really be change mgmt but part of the development cycle.

Once the production version was to be rolled out through the use of both change and release mgmt, the CI for the master application - production one - would have 2 almost identical CIs one with the old version and one with the new version. i think the term is variant

As part of the roll out of the newest version, the systems that will get the app (that is if you link the master CI varient (new) to the system / service) that is the newest and the oldest would be delinked

This action would be Config mgmt vice change...

Change mgmt would have to make sure that config mgmt is included in the process to update the CI linkages as part of the successful change workflow

The Change & release of the newest version would not get closed until all the system/service point to the new production version and not to the old version.

Once the old version varient has no linked, change mgmt works with config to retire that variant so that there is only the one for the application

Does this make sense ?
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter

[dsemeniuk]

Thanks John,

I am not sure how a Variant works as I have also read this in the ITIL Service Support book as well but am not sure how that is implemented in a CMDB.

Right now we enter one instance of a software CI for each version that exists.

So if we have software xyx 1.1 as on CI an it is installed in our testing and staging environments, it would have a relationship to those environments. So when we pull up the xyz 1.1 CI, we can see where it is all installed.

We would then have a separate CI xyx 1.0 that has a relationship with the production environment. Once xyz 1.1 is deployed into production, xyz 1.1 then gets updated to include relationships with the production environment and xyz 1.0 status would change to decomissioned or retired.

I am just looking for a simple way to maintain the relationships (server its installed on, database its connected to, etc..) that we have with xyz as all we are doing is changing the version number and am wondering if the variant concept helps with this? Instead of having to re-establish those relationships everytime we introduce a new version of that software.

[matrejekm]

RfC is assigned to CI which is to be changed as a result of RfC.

New CI comes as new Release.

RfC is closed with information which CI is the result of this RfC.
Other RfCs are related to each other or (better) assigned to a single "master" RfC with request to deliver new version of application.

Be careful and don't make it too complicated.

regards,
Mariusz M.

[UKVIKING]

dsemeniuk,

It all depends on how depend the pool is for the cmdb and whether you are tracking with the application environment the different version

for example

You have a custom application called TheApp. It is created as a CI in the CMDB as a unique entity

It has been installed on several servers - nicknamed - sleepy, dopey, doc, bashful, happy, sneezy, grumpy - which are also unique CIs.

You can link the server CIs to the one application. Each server CI would have 1 link to the App CI. The App CI would have 7 links (to the servers)

The current version is 1.01 for the app.

If you can simultaneouse (close enough ) the next version, then the CMDB work would merely update the version data in the App CI after the installation is done

If however, you plan to run version 1.02 on each server for a while before installing it on the next server, then you would create a new CI (copy/paste with new version data) for the App

As the app team rolls the new version out, part of the implementation process would make sure that the upgraded server points to the newer version.

This can be done all in 1 Change because you would have explicitly stated how you were Releasing the change. As part of the implementation plan, you would have a line.. after installing on first server, work w/Config mgmt to re-link server to new version

Once all 7 are linked to the new app CI, the old app CI state is changed to retired. as part of the closure of the change that ran this 'release'

Now the big question .. which way shoud I do it

.....

It depends on

How often you upgrade apps
How you upgrade apps
what sort of release process you have....

Now if you are tracking DLL or specialize sub apps for the apps and are merely changing them to newer version, then only the sub-app CIs get changed - either to the version number or ...
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter

[DanA]

Hmm. We are getting our CMDB up and running now. Seems to me the way we are doing it is that the CI is just the application itself and the version number is an attribute of that CI. I can't imagine having to create a new CI every time there is an upgrade to the version, having to create the relationships, etc. We just update the attribute for that CI.

[dsemeniuk]

Hello DanA,

The problem with that is that the Software could be installed in many different environments, or desktops, servers, etc... and that they may not at all at one point be on the same version as you do upgrades.

This is why we need new CIs for each version, so we can handle the relationships to where it is installed.

Therefore we cannot just update the version attribute as the relationships that the Software CI could be invalid.

[DanA]

We don't seem to have that issue, but maybe we aren't tracking quite to the level that you seem to be.

So why not why not have a unique name for each application in each environment like "SoftwareA - Desktop", "SoftwareA - Server" and still have version number as an attribute?