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.