Search
Topics
  Create an account Home  ·  Topics  ·  Downloads  ·  Your Account  ·  Submit News  ·  Top 10  
Modules
· Home
· Content
· FAQ
· Feedback
· Forums
· Search
· Statistics
· Surveys
· Top
· Topics
· Web Links
· Your_Account

Current Membership

Latest: DJoslyn
New Today: 15
New Yesterday: 141
Overall: 131706

People Online:
Visitors: 57
Members: 1
Total: 58 .

Languages
Select Interface Language:


Major ITIL Portals
For general information and resources, ITIL and ITSM World is the most well known for both ITIL and ITIL Books. A shorter snapshot approach can be found at ITIL Zone

Related Resources
Service related resources
Service Level Agreement
Outsourcing

Note: ITIL is a registered trademark of OGC. This portal is totally independent and is in no way related to them. See our Feedback Page for more information.


The Itil Community Forum: Forums

ITIL :: View topic - Changing Version of Software CIs
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Changing Version of Software CIs

 
Post new topic   Reply to topic    ITIL Forum Index -> Change Management
View previous topic :: View next topic  
Author Message
dsemeniuk
Itiler


Joined: Feb 06, 2007
Posts: 41

PostPosted: Wed Feb 14, 2007 1:45 am    Post subject: Changing Version of Software CIs Reply with quote

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.
Back to top
View user's profile
UKVIKING
Senior Itiler


Joined: Sep 16, 2006
Posts: 3260
Location: London, UK

PostPosted: Wed Feb 14, 2007 4:38 am    Post subject: Reply with quote

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
Back to top
View user's profile
dsemeniuk
Itiler


Joined: Feb 06, 2007
Posts: 41

PostPosted: Thu Feb 15, 2007 4:26 am    Post subject: Reply with quote

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?
Back to top
View user's profile
UKVIKING
Senior Itiler


Joined: Sep 16, 2006
Posts: 3260
Location: London, UK

PostPosted: Thu Feb 15, 2007 5:27 am    Post subject: Reply with quote

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
Back to top
View user's profile
dsemeniuk
Itiler


Joined: Feb 06, 2007
Posts: 41

PostPosted: Wed Feb 21, 2007 2:04 am    Post subject: Reply with quote

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.
Back to top
View user's profile
matrejekm
Itiler


Joined: May 11, 2006
Posts: 32

PostPosted: Wed Feb 21, 2007 3:15 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send e-mail
UKVIKING
Senior Itiler


Joined: Sep 16, 2006
Posts: 3260
Location: London, UK

PostPosted: Fri Feb 23, 2007 6:54 am    Post subject: Reply with quote

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
Back to top
View user's profile
DanA
Itiler


Joined: Feb 12, 2007
Posts: 27
Location: Minneapolis, MN, USA

PostPosted: Fri Feb 23, 2007 11:30 am    Post subject: Reply with quote

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.
Back to top
View user's profile
dsemeniuk
Itiler


Joined: Feb 06, 2007
Posts: 41

PostPosted: Sat Feb 24, 2007 2:09 am    Post subject: Reply with quote

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.
Back to top
View user's profile
DanA
Itiler


Joined: Feb 12, 2007
Posts: 27
Location: Minneapolis, MN, USA

PostPosted: Sat Feb 24, 2007 12:18 pm    Post subject: Reply with quote

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?
Back to top
View user's profile
Display posts from previous:   
Post new topic   Reply to topic    ITIL Forum Index -> Change Management All times are GMT + 10 Hours
Page 1 of 1

 
Jump to:  
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

Powered by phpBB 2.0.8 © 2001 phpBB Group
phpBB port v2.1 based on Tom Nitzschner's phpbb2.0.6 upgraded to phpBB 2.0.4 standalone was developed and tested by:
ArtificialIntel, ChatServ, mikem,
sixonetonoffun and Paul Laudanski (aka Zhen-Xjell).

Version 2.1 by Nuke Cops 2003 http://www.nukecops.com

Forums ©

 

Logos/trademarks property of respective owner. Comments property of poster. Rest 2004 Itil Community for Service Management & Foundation Certification. SV
Site source copyright (c)2003, and is Free Software under the GNU / GPL licence. All Rights Are Reserved.