Is software configuration management the build system's job?

tekkie's picture
tekkie asked on November 2, 2010 - 4:11am | Replies (18).

The other day I came across 2 people on the same day who told me that they believe that part of the build system's job is to do software configuration management. :blink:

Having spent nearly all of my professional life in SCM this came as surprise to me because I've tried to avoid using the build system to manage software configurations, and whenever I've come across these build systems these were highly complex solutions with lots of gotchas and usually created in part from a legacy environment that used 'simple' version control tools.

Both of these people happened to be Subversion advocates and it got me wondering whether this has anything to do with the fact that Subversion was built as a replacement for CVS and doesn't have the notion of configurations.

What do you say? Is Software Configuration Management the build system's job? Or is it a shared responsibility between the SCM/VC system and the build system?

- Antoni

18 Answers

baynes's picture
baynes replied on November 2, 2010 - 6:33am.

There should be a separation between the basic build and the CM but there may be good reason to link them at a higher level.

The basic build should ideally be CM un-aware and work from a workarea. However round that you may want to wrap a layer that sets up the workarea from a configuration invokes the build, sends the result somewhere special and applies tags to the CM system. This could take the form of a continuous integration server or a specific release script (or even both). But this upper layer should treat the actual build as a black box.

You need to keep these layers distinct otherwise you end up with a complex muddle as you describe.

I expect there are exceptional cases where you have to mix them. But I would keep them as exceptions rather than the norm.

Udovichenko's picture

Hi tekkie,

It's that simple: Build Management is a part (a subset) of Software Configuration Management, not vise versa. Thus, you cannot make SCM "a build system's job". You'll have source code management (version control), build management, issue tracking etc. - combined together. You'll even have some ALM solution, but it's NOT build systems' job to handle the whole SCM.

It's like somebody say "it's the engine transporting me and my car is my engine"... absurd, isn't it? Your car has an engine, but it's not all, you got lots of other parts combined together.

P.S. And the subject defenetly has nothing to do about SVN or CVS :)

bglangston's picture
bglangston replied on November 3, 2010 - 1:29pm.

I have always maintained, and continue to maintain, that "build" is not a part of CM nor vice versa. They are two distinct practices. In my view, build is a step in the creation of a product and as such is part of the line function (in the old management terminology of line and staff).

Build is in essence the action taken to translate man-readable material (source) into machine-readable material (executable).

Determining the components to include, which versions of the components, which set of build instructions, and which build engine is the responsibility of someone such as the team lead or PM. Putting the package together for the build and delivering it to the Build Engineer (BE) is the role of the CM specialist. Those duties are not part of actually performing the build.

Now often the person who is assigned to the role of CM Specialist is also assigned to the role of BE. Why? Probably because it is cheaper. You don't have to hire and pay for the benefits of a separate BE.

With all that said, it may be that the build system contributes to CM activities if the system has features that normally are done by other means. For example, in the old days, versioning/revisioning was done by hand. Someone finally automated that so that a CM tool would do it as updated files were checked in. Now if you have a build system that contributes to that, then you could claim that the system contributes to CM activities. But that is a long stretch from saying that either one is a part or subset of the other.

mbools's picture
mbools replied on November 4, 2010 - 5:25am.

I agree with baynes and blangston. Build is a separate function to CM. If you need an umbrella term how about ALM (I prefer to think of IT Systems Lifecycle Management rather than Application Lifecycle Management because in my experience there's usually more to consider than just the application, but that's just me).

Eric Minick's picture

It can be a blend.

You mention that determining which components (and versions of those components) should be used is the job of people. That should be true, until the people decide that there are obvious rules like "Use the latest version of the logging library approved by the security team" or "Latest build of that other related project".

Once there are rules, the mundane work of actually looking up the correct version and provisioning it into the build workspace can, and should, be handled by the build system. All mundane, repetitive, rule based work should be pushed to automation if possible to free up smart, creative, and less consistent people to work on interesting things - like defining the darn rules in the first place.

I suspect the SVN folks are used to working in a straight forward environment where clear rules made it easy to offload the work to automation. If the rules aren't defineable in your environment, the first question to ask is "why?". Is it because it's hard to formally track what's approved / released / built from various teams? You can fix that. It's possible that things are genuinely hard and human intervention is required. That tends to slow things down and I try to drive it out of the process where possible.

Keep in mind that there is a difference between a build tool like Make and Ant which are compile / package tools and larger build management frameworks which handle component provisioning, etc.

jptownsend's picture
jptownsend replied on November 9, 2010 - 2:27pm.

Mark and Billy,

While I normally agree with everything you say, I have to disagree on this one. Mark you stated:

"Build is a separate function to CM"


Configuration management (CM) is a field of management that focuses on establishing and maintaining consistency of a system's or product's performance and its functional and physical attributes with its requirements, design, and operational information throughout its life.

Even though this standard is outdated one could argue that this could be referring to a build function in CM.

One of the four activities of CM is the following:

Configuration change control is a set of processes and approval stages required to change a configuration item's attributes and to re-baseline them.

One of the things that a Build Engineer does is baseline every time they build or they should. I think we would all agree that a build constitutes a change to a executable, jar files, war files, dll's, etc. attributes.

I know Billy that you feel that Build is not part of CM at all. I disagree with that due to the above and the separation or segregation of duties necessary to make sure only configured, tagged or baselined code makes into a build. Who can make this decision better than anyone? I say the CM folks since we are responsible for the integrity of the end product who better to build it?

Just my two cents,


mbools's picture
mbools replied on November 10, 2010 - 7:09am.

Well Joe I guess you had to be wrong one day :P

Rather than make an extended point by point response to your post (mainly because I do not read the quoted standards the way you do--if one is willing to grant such generous latitude in interpreting the quoted sections to allow build to be included in the CM function then one could also include development under the same umbrella) I will simply reframe (or rather expand upon) my own position.

To restate what Billy said, build is a function that takes a baseline of source items supplied by the CM function, processes those items to produce some 'product' items, which are subsequently baselined by the CM function.

When you say... "One of the things that a Build Engineer does is baseline every time they build..."

I disagree, to the extent that the build engineer may have been provided with tools to create a baseline, and indeed may be tasked with creating that baseline, the responsibility for defining and assuring these baselines remains with the CM function.

To say that the build engineer is part of the CM function because they create baselines in this way is like saying the developer is part of the CM function because they submit changes to a version control tool that are picked up by a continuous integration build system which automatically creates a baseline for a nightly build. Developers indirectly create baselines as part of their work, ergo they are part of the CM function? I don't buy that logic at all.

I have said this before but I'll say it again, just because these two functions are often conflated under one role title does not make them the same function. They provide very distinct services and require distinct skill sets. The skills and temperament required to properly create and audit baselines (for example) are not the same as those required to create and administer a build system. However, it is true that many SCM people are, by virtue of background and experience, often skilled build engineers too. It is hardly surprising therefore that organisations often have the one person perform both roles.

mbools's picture
mbools replied on November 10, 2010 - 7:33am.


I think you are confusing automation of a policy with the establishment of the policy.

When you say..."You mention that determining which components (and versions of those components) should be used is the job of people. That should be true, until the people decide that there are obvious rules like 'Use the latest version of the logging library approved by the security team' or 'Latest build of that other related project'. Once there are rules, the mundane work of actually looking up the correct version and provisioning it into the build workspace can, and should, be handled by the build system. ..."

I agree that automation of policy is, on the whole, a good idea and I certainly strive to automate as much of my work as I am able to. However, this does not transfer these functions from CM to Build. It transfers, in part, the execution, but not the responsibility or authority.

It is for the CM function to define and, where necessary, approve the automation of CM related decisions. If your CM function allows the automation of a decision such as "Use the latest version of the logging library approved by the security team" then that is a CM function decision. The fact that this decision is then automated and integrated into a build system in no way makes it the responsibility of the build function and certainly does not transfer authority to decide whether that policy should be applied or not.

To draw an, admittedly less than watertight, analogy. The law is laid out (in the UK) by parliament and the courts. These bodies are responsible for the establishment and administration of legal justice. The police force are tasked with enforcing the law, but have no powers to modify the law. So, the police often enforce some, clearly defined and unambiguous, laws without recourse to the courts (littering fines, for example, are easily defined and penalties automatically enforced), but when a legal decision or interpretation of law is required it is not for the police to make a determination but the courts. The CM function is analogous to parliament and the courts, defining the 'rules' and administering those rules (and where necessary, arbitrating the correct interpretation). The build function is, in this context, acting in accordance with rules already defined by the CM function. The build function has no right to deviate or redefine the rules and whenever a circumstance is encountered that does not fit neatly into one of the prescribed rules ("Use the latest version of the logging library approved by the security team") the build function must defer to the CM function for a decision.

Okay, there are plenty of holes in that analogy, but I hope it makes the point that the build function, whether automated or not, is not part of the CM function, it is only enacting policy already established by the CM function.

So, yes. I agree. Automating CM policy as part of the build system is a great idea (with the caveat that the CM function is still responsible for auditing the results to ensure compliance, relevance, and accuracy), but this does not make the build function part of the CM function.

Eric Minick's picture

Mark, I think we may agree completely. The CM team should set the rules, but the actual day-to-day grunt work of implementing them should be offloaded.

Get back to Antoni's question, I wonder if the confusion between policy creation and execution has lead to the discover of the two engineers who think the build system, "does scm".

If those developers viewed "doing scm" as the execution of the policies, it would be less than insane for them to make statement that on its face seems silly.

jptownsend's picture
jptownsend replied on November 10, 2010 - 10:28am.


I guess will have to agree to disagree. But keep this in mind, I say as a CM person I typically don't do that many CM activities, it is either done by developers or testers. Now they may or may not know they are doing CM things but they are. So if you look at CM activities I would go so far as to say that Developers do about 50% of all CM activities and testers about 40% and CM folks about 10% at least that's been my experience.



Marc Girod's picture
Marc Girod replied on November 11, 2010 - 6:38am.

tekkie wrote: "What do you say? Is Software Configuration Management the build system's job? Or is it a shared responsibility between the SCM/VC system and the build system?"
I don't really agree with anybody on this thread...

The problem is probably in the question, and more precisely in the 's' predicate.

SCM is about management, and shouldn't make sense unless it would be itself manageable. Thus it has to take responsibility for its presentation of reality: it cannot accept arguments of authority. Thus nothing "is" unless we want it and know why.

The special kind of sophisticated SCM I'd wish to achieve/evolve (trying to avoid the word 'build'), based on concepts taken from clearmake, would reverse the terms of the assertion: SCM is a by-product of Build Management.

I have already attempted to develop this idea, but here is a new bit of argument: identification makes only sense for stable artifacts. Unless the SCM/build tool provides a way to promote, save, and share derived objects], the only stable artifacts are (hand-produced, and thus slowly changing) 'sources'. But as soon as the life-time of DOs gets extended, it becomes possible to base the whole identification on 'them', and 'this' makes much more sense than the traditional state-of-things.

This is because DOs have more intrinsic value, because they have a structure (based on dependency graphs), and because they may typically be run (they don't need to be painstakingly interpreted.


Eric Minick's picture


This is the religion Urbancode (my employer) preaches around AnthillPro. The "build" part is often the least exciting element of what we do. Automated execution of build steps should be routine by now (although managing DOs from other components is interesting).

The exciting part is capturing the derived artifacts into a built in artifact repository for controlled migration through the release pipeline (deployments / tests / approvals / etc). A build merely starts a "Build Life" - that thing you share and promote and track.

And now, I'm guilty of a dirty vendor post, but I couldn't help it. We agree too much.

Marc Girod's picture
Marc Girod replied on November 12, 2010 - 12:27pm.

Eric Minick wrote: "And now, I'm guilty of a dirty vendor post, but I couldn't help it. We agree too much."

Thanks Eric. Very interesting. I have to read more about AnthillPro...


bglangston's picture
bglangston replied on November 26, 2010 - 12:25pm.

Wow, Joe! Looking at your last post reminds me a question I once asked on the Crossroads. I don't have it at hand, but it was something like, "How much CM does the CM specialist actually do?"

At the time my answer was something like "after the planning, very little" except ride herd on the CM system and compliance with it. (In some organization, the latter can be like herding cats.)

For Identification: The CCB (or similar authority) determines what will be formally controlled. The developers/creators apply the identifiers. The CCB (or similar authority) determines the baselines (or delegates the authority to a level more suitable to the organization and product.

For Change Control (Configuration Change Management): The CM specialist plans the request for change system, but it is the people on the contract who prepare the requests, tech team who analyzes it, the CCB who approves/disapproves, the tech team that incorporates it, and the build engineer (who, in software but not in ships and tanks and trains, OH MY, may be the CM specialist) creates the useable product. The release manager (probably the same person as the PM or a delegated technical authority) determines what will go into the release. The CM guy will probably be the one to gather the materials into a "package" for the build engineer.

Status Accounting: In the old days, this was done by hand by the CM specialist. Now, the specialist plans the reports (based on management needs and desires), and extracts the report information.

Audits: Functional audits and audit reports are performed by testers, customers, stage gateway teams and the like (usually with CM specialist participation but not CM specialist responsibility for successful products). Physical audits and audit reeports are performed by designers, customers, stage gateway teams (insert above remaining text).

So, I'm not sure about the 50% and 40%, but after the planning, I'd say your 10% for CM folks is a little high on direct CM activities, but can be higher on managing the CM system.

Happy belated Thanksgiving to all.

pascal.van.kempen@topic.n's picture

Interesting discussion. I was mainly triggered by the first statement: is CM part of buildmanagement?
I am used to the other way around: buildmanagement has been added to CM (and from the posts I see I'm not the only one ;) ).

To my opinion, the borders between configuration- and buildmanagement have become more and more vague, especially with the evolution of continuous integration

Deliveries of source code are automatically baselined, the baselines are automatically build, build results are automatically tested and when succesfull, baselines are automatically propagated to the developers.

Preferably all of this automation is managed via one tool.
Did I say tool? Okay, so where have the buildmanager and the configuration manager gone?

That brings me to the latest post of bglangston: how much CM does the CM specialist actually do?

Based on my own experience (in 15+ years of CM) I've observed a shift in the CM tasks. When I started, most of the CM work consisted of making baselines, defining labels, writing config specs (in ClearCase), supporting merges and so on.
Nowadays, where most of these tasks are (partly) automated, the focus has shifted to the strategic part of CM, like how to conduct parallel development in your CM system; how to release and merge in an efficient way; how to allign your branching strategy with the company's roadmap and so on.

But also: how to apply the SW CM experiences to hardware CM and documentation CM.

In the early years, conducting CM and performing builds was very labour- and timeconsuming. People only dreamed of parallel development and continuous integration. It simply costed too much time to do so.

Nowadays, with the sophisticated tools and fast build engines, we can do more with less effort. This makes it possible to support parallel development, parallel releasing and so on. But this requires a new focus area too. It's not anymore the day-to-day business you have to take care of (that is automated) but the long term vision and strategy.

davidbfoster's picture

Based on my 15+ years in CM, I agree with Mr. van Kempen. A CM specialist must know multiple tools and be able to speak to management about CM functions. We must be able to take any CM discussion to an Enterprise level without upsetting anyone.
As for the Build Manager and Configuration Manager, they have become one in the same in the recent CM activities I have seen.

dgeorge83616's picture

Funny coincidence that another place I lurk is having a discussion about whether CM is part of production or development. In the other discussion I argued that CM should be independent of both. I think it is appropriate here, too.

CM is too important to dilute it with build activities. There is nothing CM can do to fix or break a build. It is the developers who do that. CM's job is to provide a process for managing specifications and facilitate its execution. If you put build under CM the staff will be driven to fix builds rather than facilitate spec management. They will end up managing the specs directly and only at the most inefficient level, source code.

How to obtain the specifications and managing the build workflow is production's job. This function is (should be) fully automated but someone has to maintain that automation. CM and production are two different activities with differing objectives requiring different skills, inclinations and interests.

bglangston's picture
bglangston replied on December 30, 2010 - 11:27am.

Here, here!
You said it much more eloquently than I did, but your post was what I was trying to say.

To carry a bit further (I'm nothing if not verbose), we need to remember that CM is not an activity. It is a discipline, a specialized form of management discipline.

Folks, please don't confuse the definitions of management as a discipline and management as a group of folks who "run" the organization. Unfortunately, because of confusions about meanings, many often assign the first idea that comes to mind. They grab the low-hanging fruit rather than investigate to find the real meaning. Or, they simply accept what was stated because they don't know any better.

For example, a few years ago no one ever thought of having a CM specialist doing a software build. Then someone discovered that you didn't necessarily need SW expertise to perform the build function (probably a vendor who likely proposed saving the expense of hiring a build engineer "because with our tool, the CM person can do it").

However that happened, we started seeing job posting for a CM Specialist with a job description that included "Must be experienced in performing builds."

As to the question of "management versus production/development," CM is in my opinion most definitely in the management category. Please note that no document that purports to be a "standard" allocates actual activities to a CM specialist. All the "standards" I have seen, not all of them I'm sure but still a large number, state the activities that must be done, but not one tells us "how" or "who," except the nebulous reference to a "decision makeing authority or body." A couple of those standards even go so far as to add "(sometimes called a CCB").

With that said, CM is in my opinion very closely aligned with another specialized discipline called "industrial management." Although the products are different, their relationships to the more generic management discipline are similar. The easiest way for me to express it is to say that on a project, project management is concerned with a lot of "stuff" like personnel, financials, schedules, human resources factors, customer coordination, product delivery and myriad other things. To accomplish all that, the project manager may have a staff of people to oversee/manage specific pieces (recruiting manager, project finance manager, etc.), each of whom applies the principles of his/her specialty to satisfy the projects management requirements.

In our case, we are, or should be, concerned with managing the product. (This is another place where terminology is often cavalierly tossed about, i.e., product vs project. As in, "Our project is the xyz application." No, the "project" is to CREATE the xyz application; thus, xyz is the product.) Ensuring that the product goes through all the right loops to guarantee(?) that it is the correct product is the domain of the CM discipline. It is the CM specialist who does all the planning, organizing, coordinating and controlling the CM processes and activities. (Control here refers to taking feedback and making adjustments in the CM system.)

In a nutshell, CM is definitely in the management arena and not a creating activity. On the other hand, "build" is a creating activity. Therefore, "build" is not part of CM.

CMCrossroads is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.