Change Control Gone Wrong
Change Control & Release Management are two of the most fundamental elements in software engineering. You write code. You release code to the world. All the while, track changes to the code in case something goes horribly wrong and you need to revert to a previous version. It's pretty simple.
Modern change control systems like CVS provide additional functionality. When checking in changes, you can include comments to describe the changes. Tagging the repository ties various versions of source files together (i.e. for a release). Branching involves splitting the repository so parallel development can take place (i.e. to support bug fixes to a release while the next version of development continues on the trunk). Changes on the branch can be merged into the trunk, eliminating the need to apply fixes twice.
These features are fairly standard in most of the change systems software development teams use today. The point of this post is to ask why some organizations are reluctant to use these features?
The process where I currently work is this... Write the code (the method of version control varies by team). While the company has purchased a version control system for production releases, it wasn't available for development teams to use until recently. Even still, the development and production version control systems are completely separate.
What this means is, once the code is ready for promotion, the code is exported from the development version system and imported into the production system via copy/paste to a directory. When an enhancement to the production release needs to be made, the process is for the production code to be imported back into the development system where the changes are made.
I have a few problems with this. First of all, the version history and comments describing the development changes are lost during this import/export process. This information can provide assistance to the development staff in understanding what changes were made, by whom, and why.
Secondly, you lose the ability to merge production fixes automatically to next-release code currently in development.
Understand that the version system this company purchased has the ability to tag, merge, branch and do all the things described above yet they decide not to - instead relying an archaic system of manually copying files around to various directories. This nullifies any value provided by the version system! Why not just copy the release code to tape? All I can guess is, for some reason the company doesn't trust the tool that it bought.
The dirty secret in all of this is, the company's process is a total waste of time and resources. The development team is never going to use the supplied "production code" when a release needs enhancement. The development team is going have a tagged version of the release in the development version system to branch on. It will automatically merge any changes to the trunk when done.
For some reason, the necessity of this charade really bothers me. Getting something so simple wrong, leads me to question how this company can make good decisions when the issues are more complex.
Modern change control systems like CVS provide additional functionality. When checking in changes, you can include comments to describe the changes. Tagging the repository ties various versions of source files together (i.e. for a release). Branching involves splitting the repository so parallel development can take place (i.e. to support bug fixes to a release while the next version of development continues on the trunk). Changes on the branch can be merged into the trunk, eliminating the need to apply fixes twice.
These features are fairly standard in most of the change systems software development teams use today. The point of this post is to ask why some organizations are reluctant to use these features?
The process where I currently work is this... Write the code (the method of version control varies by team). While the company has purchased a version control system for production releases, it wasn't available for development teams to use until recently. Even still, the development and production version control systems are completely separate.
What this means is, once the code is ready for promotion, the code is exported from the development version system and imported into the production system via copy/paste to a directory. When an enhancement to the production release needs to be made, the process is for the production code to be imported back into the development system where the changes are made.
I have a few problems with this. First of all, the version history and comments describing the development changes are lost during this import/export process. This information can provide assistance to the development staff in understanding what changes were made, by whom, and why.
Secondly, you lose the ability to merge production fixes automatically to next-release code currently in development.
Understand that the version system this company purchased has the ability to tag, merge, branch and do all the things described above yet they decide not to - instead relying an archaic system of manually copying files around to various directories. This nullifies any value provided by the version system! Why not just copy the release code to tape? All I can guess is, for some reason the company doesn't trust the tool that it bought.
The dirty secret in all of this is, the company's process is a total waste of time and resources. The development team is never going to use the supplied "production code" when a release needs enhancement. The development team is going have a tagged version of the release in the development version system to branch on. It will automatically merge any changes to the trunk when done.
For some reason, the necessity of this charade really bothers me. Getting something so simple wrong, leads me to question how this company can make good decisions when the issues are more complex.
Comments