the correct approvers associated with the component and the cross impacted functional owners which could experience a problem due to any given change being propagated thru the life cycle. Development, QA, integration, and finally production environmental impacts should all be taken into account.
Where does SCM fit into the scheme of things? Let’s get back to the foundation of all change! Any piece of software which runs on technology should be archived within your SCM tool. This enables everyone to understand what versions of code you are running, which version was last installed as well as who submitted any given version of source code, script, object, binary or any software within your entire infrastructure. (It sounds like SCM should feed Asset tools too doesn’t it?) Many SCM tools store and version binary as well as source and this is very important. Not only can you safely store all software within an SCM tool you can always fall back to a previous version since it can never be removed if properly archived within the SCM DB. Hopefully your SCM tool has a release functionality whereby you can build a package containing all the components being installed within a release. This packaged release should be able to promote through a life cycle from a basic unit test to development environment, to a QA environment and eventually production.
One package that has not changed from the time is has been cast into the technology pond should be able to run in each stage or state that it enters if no functionality failures occur from that package. How to maintain as close as possible the environments for both hardware and software between life cycle stages is another story for another time but is part of this process. If problems have been found in the QA environment than the release could be altered but only by those entitled to make changes in a given stage or state. Your best bet would be to reject the package or back down the package to the previous state, fix the failures and have the package recast. In a perfect would each and every package/release would promote up the life cycle without failures but we all know better. We also know that all packages/releases are different every time so careful vision of impact and risk is critical. Collision between packages going through the life cycle is also something which needs clear vision and of course there are merge tools within many SCM products to ensure you do not impact the same code avoiding stepping on each others code (toes). Managing merges is a process that requires careful thought and of course the proper diligence to ensure risk and impact is lessened.
I will not get into the build process at this point because many SCM tools require third part build products or they utilize in-house scripts already built for their current build process to create the binary which should then be versioned in the SCM tool. This is an unfortunate by-product of the complexity of building code with many different IDEs or build tools used throughout the industry. Nowhere is there one-stop shopping for build tools available. There are ways to standardize the build process throughout your enterprise which will simplify everyone’s life but that too is another story for another time.
The major disconnect experienced with the full change event management process is that CEM tools which maintain event approvals and get populated hopefully with the cross functional impacts is that they do not communicate with the SCM tools. In a perfect world you open a change record