Configuration Management (‘CM’ hereafter) means a lot of different things to different people. Weighty tomes have been written describing the goals, policies, procedures, benefits, pitfalls, and a variety of definitions of CM. One recent CM plan I worked on is a 20-something page document attempting to detail this information and how it relates to the client’s projects.
Most of the information available can be boiled down into 4 key concepts, or what can be called the 4 cornerstones of great CM. These concepts represent ideals. The challenge is in the implementation, so that the policies, procedures, and utilities developed support these ideals, or at least the intent behind them.
Version control – Everything is maintained in a Version Control tool like those offered by Serena (commercial software) or Subversion (Open Source). Some agreed set of items (Configuration Items, or CIs for short) stored within the tool represent baselines. In other words, they are the set of revisions currently in production. They are not necessarily the most recent revisions. Builds intended for deployment to any post-development environment (QA, Test, Prod, whatever) are always pulled from Version Control, and never copied directly from a development environment.
Separation of Duties and Least Privilege – Actually, these are two principles lumped together because Least Privilege is not possible without Separation of Duties, and Separation of Duties is pointless without Least Privilege. The former simply means that no single person has independent responsibility over more than one area of a system. For example, developers change code, perform unit test, etc., but do not deploy or promote such code to any non-development environment. CM people promote code, but do not develop applications, nor do they approve code changes made by developers (although they may participate in code reviews). DBAs have database privileges, but don’t develop application code nor act as system admins. And so on. The Least Privilege principle simply states that no person or running process has more access or system privilege than they need to perform their normal duties or functions at any point in time. Access or privilege for either people or processes can temporarily be increased during the performance of some activity as necessary, then immediately restricted again. Policies implementing these controls make allowances in both these principles for emergency situations.
Auditing – CM personnel periodically conduct audits of applications, systems, and procedures. Any updated application software or configurable item should be traceable to an approved change request, as well as through the entire set of existing quality control, tech review, and change control procedures. This includes not only application executables but database configurations as well. All items are compared with their baseline counterparts in the Version Control repository (ie; the revisions marked as ‘Production’). Discrepancies are reported as non-compliance issues and investigated, and will generally lead to procedural changes designed to eliminate future non-compliance.
Automate, Automate, Automate – This one is an over-riding theme for how we accomplish all this with limited resources. Checking items out of and into Version Control should be quick and painless, and integrated into development IDEs (Interactive Development Environments) if possible. Code promotions are scripted. Database changes are scripted. Auditing utilities are scripted. These scripts themselves are subject to review and kept in version control. Tying it all together gives us reliable, secure systems built with verifiable, repeatable and efficient processes.
