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
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 - Changes to Development Environments
Posted: Fri May 25, 2007 1:03 am Post subject: Changes to Development Environments
Hi All,
I’ve implemented a Change Management process based on the ITIL guidelines at my current company and I’ve been asked by the Release Manager if I can incorporate changes to some of the development environments (eg UAT, Production Support). In previous experience I’ve only ever managed changes to the live production environment but I can see from the Release Manager’s point that changes to the Production Support environment could impact our production activities. I’m looking at the best way to implement this and am considering an additional lifecycle or maybe a different way of labelling development environment changes so they stand out. I will also be extending my CAB meetings to ensure Development is represented properly.
If anyone out there has experience of managing dev changes any advice/tips would be gratefully received
We currently are managing all of our environments, Development, Testing, Staging, and Production through our Change management process.
Any changes to these environments require an RFC with the exception of custom software development specifically targeted for the develpoment environment, we do no put change control around that but we do have change control around the hardware and COTS for that environment.
We are currenty treating our Testing environment and staging environments like production as these environments have end users and need to be made aware of any changes.
So if the development team wants to deploy a new version of the software they built into the testing environment to address any defects or new functionality that was requested, they fill out an RFC for review to ensure the release is reviewed properly, ensure Release notes are sufficient and the CIs changing are listed, testers are aware of the changes and can test them properly, implementation plan is in order, roll back, etc... Once approved by all parties it is then scheduled at the appropriate time and communicated. CMDB is updated as well once RFC has been implemented.
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