Software configuration management systems must be designed for change.  This need is easily recognized by the simple fact that software organizations are constantly in a state of transition.  There are requirement changes dues to organizational growth and SCM Stakeholder Transitions, plus rapidly changing technology advancements are driving the need for SCM changes.

Some really cool plugins have been developed to help with this change, but I’m averse to using them for reducing short-term configuration time by tightly coupling two parts of the SCM system together.  This is often done at the expense of making future changes more difficult.

One example is utilizing a continuous integration server plugin for publishing builds, such as the TeamCity-Artifactory plugin.  This plugin will save you from having to include artifact publishing as part of the build scripts, but you will have some redo work if you want to change the CI server.  This kind of rework means it could be much more expensive to change integration systems when a new product comes along, or if your company decides to cut expenses by switching to an open source system like Jenkins or Travis CI.  The SCM design is likely to more flexible, at least from a CI server perspective, if a build technology plugin, such as the Gradle-Artifactory plugin is used for publishing.

Another way to keep your SCM system changeable is to avoid engineering build scripts to be dependent on code stored in a specific version control system.  One way this can happen is if the build script retrieves the revision number and uses it as the build number.  This will complicate a migration from one VCS to another at some point in the future.  A better design is passing the revision number to the build script as an argument – making the source code tree version control agnostic and easier to move.

Just as with code modules, reduced coupling between the underlying technologies in the SCM design can simplify re-engineering when changes are needed.

SCM is Changeable