Just as we design software to be modular, I like the idea of designing SCM to be module. After all, SCM is Software. A simple design pattern taught to me in the early 1990’s has proven effective when applied to build engineering. Note that from my perspective, the term build is a general term used in reference to any integration activity including compile, test, bundle, package, and deliver.

The basic input-processing-output pattern used by COBOL programmers has proven itself to be valuable as the basic building block pattern for continuous integration of enterprise software build products; and there is no reason to think it wouldn’t work just as well for continuous delivery, and any other continuous (i.e. fully automated) activity. The pattern is flexible and scalable to fit any size modular software component or product build.

The intent of using this as a build pattern is to keep your SCM system modular and flexible:  write your source code to be version control system agnostic to maintain and capable of downloading binary sources from any type of artifact repository [the inputs]; design your builds and tests to be continuous integration system agnostic [the processing]; and maintain the ability to publish artifacts to any artifact repository or deliver software changes to any software system [output],   The intent of this pattern is to remain agnostic of the supporting SCM systems.  Internally coupling any of the three parts of the build pattern to a single manufacturer’s application should be avoided.

Keeping the SCM system modular and flexible also means you must prevent instances of the the core build pattern from becoming tightly coupled with each other. In other works, preventing external coupling together of the builds is just as important as preventing internal coupling if we are to meet the objective of maintaining system flexibility. This can be a challenge since there are multiple tools [and of course, more of those magical plugins] available to assist you with activities like triggering builds.   You will be wise to stay out of these traps. In some cases, their main purpose seems to be keeping you locked into a specific vendors software and paying to lease software. Has this ever happened to you?

But let’s also be careful not to chain together builds [or tests, or deployments, or deliveries] by tightly coupling build processes together within a continuous integration system. It’s loosely coupled when you have build process A producing artifact A for consumption by build B; and more tightly couple if the output of build A is directly input to build B. Both may seem the same, but they are quite different. This difference becomes apparent when adding a new build C, with a need for consuming the output of build A. With the loosely coupled solution, builds A, B, and C can all be easily be executed on different continuous integration systems.

SCM is Modular