Tracking a Release

[dsemeniuk]

An RFC comes in to say they want to make a change to an application. Say add a new field on the screen to capture some information.

It gets approved as everyone agrees the change is needed.

Questions:

1) How do you schedule this type of change, as in when will you know it will be deployed into production?

2) How do you track the development and testing through each of the environments (Testing, Staging, and then into production)

I guess I am wanting to know the status of the RFC that is being used through these stages and how change and release work together to track the new version of software being promoted into different environments, basically being installed on different servers as it passes testing and then finally into production. What process do people use to track this in the CMDB and communicate to people that a new version of software is being installed and an outage maybe required.

Thanks.

[UKVIKING]

If your deve environmetn has their own release /version control system/process, then let it run through that

if not, and it is current practice to have dev work through change keep with

same for uat

BUT...

once they plan to do the work to the live environment, the change needs to say about the dev and uat work and the success etc of the release
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

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

[dsemeniuk]

I guess what I am looking for is, once the RFC has been approved to be built.

What process would track its progress from Dev to Test and then finally to production, as in keeping the Status of the CI and RFC to reflect where it is and who that gets done.

Right now we are tracking versions of our custom applications within our CMDB through each environment based on RFCs being submitted before deploying into each environment, that is our key to update the CI status.

My concern on this is that this could get out of hand with multiple streams of development (Prod Support Stream, New Development Stream) and trying to keep the relationships of custom software as to where they are installed could get ugly.

I am picturing just managing the Production environment versions of custom applications (where they are installed, connected to, etc..) and let some other process manage the promotion of these customer applications into the prior testing environments.

I am looking for how other people manage this scenario.

Thanks.