Posted: Wed May 02, 2007 12:25 am Post subject: Tracking a Release
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.
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.
Joined: Sep 16, 2006 Posts: 3589 Location: London, UK
Posted: Thu May 03, 2007 12:00 am Post subject:
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
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
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.
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