Where do Builds fit into the CM process?

Joe,

You said “No, the QA or QC person does not test the fact that version 1.3 of foo.c and revision 2.8 of billy.vbp was used, they have no idea. They test the final product, the executable, the war file, the website, whatever. The job of knowing what is in the build belongs to CM. Now in a sense someone could say they are testing the individual files, but from a QA/QC perspective they aren't.”

I didn’t say, “QA person;” I said “QA function.” However, your comment that “they have no idea” begs the question: Then what do they do? I would suggest also that while your first sentence above might be true [i]in your environment[/i], it is not a universal truth. In some environments, such verification is one of the tasks assigned. It might or might not be the QA person. It might be the CM person (I send the files to the build engineer, then go down and make sure he/she used only the sent files.) or some other member of the project team.

But more generally, your first two sentences are not necessarily true. Maybe the QA or QC person does not test the fact (in your or other’s environments). But historically, especially in very large, very complex, very expensive, and very critical projects (where people's lives depended on the product), performing builds often are done by dedicated build engineers. The second sentence is also not true. Testers do the testing. (And, depending on the type of test, those testers might in fact be users rather than members of the “test team.”) (In fairness, I think I caused at least a part of the problem with paragraph. When I used the phrasing “tester/auditor/verifier,” I was thinking in terms of “someone who would perform the verification.” I probably would have been clearer if I had said “tester, auditor, verifier or whatever you want to call the person who checks the correctness of the contents.”

Anyway, there are several ways to ensure the proper set of files gets used. Here are three:

1. The low-hanging fruit is to have the CM person verify the files by doing the build him/herself. But who verifies the files that the CM person used. (Single point of failure!)
2. Have the CM person send the files to the build engineer. The weakness here is that the build engineer could still use files from his/her desktop.
3. Have the CM person send the files to the build engineer and have a third person (QA function) verify the files used. (Not often done this way because it's expensive!)

On the second question, your response seems to look only at the final product. There is nothing that I'm aware of that says QA/QC is not a continuous activity throughout the process. In fact, quite the opposite is true. In the case of the house, the final inspector, which in this case would be the “tester,” might not check locations of studs and spacers. On the other hand, if he’s conscientious he might well bring a stud finder with him for that very purpose. As a practical matter, the Construction Manager or foreman should/will know and verify spacing [i]as the house is being built [/i](when they can see the innards). You are right in saying “they only have visibility into the outputs of a build, not the inner parts” [i]IF the CM person does the build[/i]. But even then, wouldn’t the Release Review Team look at the inner parts that went into the build?

On the third point, you stated that when a CM person does a build, they also baseline the CI's that make up that build. Of course they do and that is part of the CM function of Configuration Identification. But relative to the build, that is part of build preparation and has nothing to do with whether or not performing builds is a function of CM.

“(Am I) going to trust the developer to baseline the code and not make changes to that baseline without permission?” Of course not! That would be a blatant conflict of interest. Your response seems to assume the developer is the only alternative. In fact, I worked on one project where the build engineer was a qualified programmer (but not from the development team or even the same contractor). His problem was his ego. To show his expertise in the language, he would go in and correct code to “force” the build by modifying code on the fly; and, yes, it did cause major problems. When he was informed of the error of his ways, he refused to change (because it is “easier to change the code than to prepare those $#^%& error reports”), and was replaced. (It was the QA person who “discovered” that he was not following the rules.) The new build engineer worked wonders by providing the appropriate error reports for proper processing so the developers could make the corrections.

You further state: “Now for me I as the CM person want to not only identify the baseline and its changes, but also make sure that no one is changing that baseline without approval.” And so you should make sure. That is called Configuration Control, and is only one strong reason why “CM is a pillar of the builds;” but again has no bearing on “performing builds” as a function of Configuration Management. It also does not explain how performing builds yourself reveals unauthorized changes. That revelation comes before the build package is created. Again, that comes from proper Configuration Control, not from personally performing the build. (It also begs the question of how do you know there are no unauthorized changes to the SRC unless you read all the lines.)

For example, while correcting an error on line 5, the developer notices and changes something else on line 7. You look and see that the line 5 change is correct as authorized. Unless you can read code, how do you even know the change to line 7 occurred? – but that is another issue that really has nothing to do with performing builds.)

On the section about money and integrity:

Money is not a “moot point.” Money IS the point. Regarding trust, does the position of CM Specialist somehow guarantee trustworthiness? If said trustworthiness is such a non-issue, then why does the Configuration Management Audit exist. Everybody knows the CM Specialist is totally trustworthy so why do we need to audit the CM holdings usually with at least a QA person and the project manager in company.

You said, “Since CM is responsible for the baseline and any changes, they should be responsible for the build that determines if the changes to the baseline are truly legitimate.” As I asked above, how does performing the build determine if the changes to the baseline are legitimate? That revelation can only occur prior to the build (during normal Configuration Control process or during the build preparation.) The build will only tell you whether the product will build or not. Oh, the build machine might tell you where it hangs up, in which case you can research to find out if the hang was caused by an unauthorized change. (Is that any less true if someone other than the CM person does the build?) But, if it builds, how do you know it’s because ONLY legitimate changes were made? It is not necessarily true that non-legitimate changes will cause a build failure. In fact, the build might be successful precisely because a non-legitimate change was made in line 7 to go along with the legitimate one in line 5. (And yet you would have no record (CR, CCB approval, etc.) of that line 7 change.)

To your last point: “While the four activities of CM have not changed and never will. How we manage them and verify them has, and every position evolves and CM is no exception.” I disagree. First, you speak of the “position.” Nowhere have I said that the CM person should not do builds. My point has been that [i]whoever performs the build, doing a build is not a function of CM[/i]. CM as a discipline has not changed for a long time, except for the addition of Planning. All the principles and requirements remain. What has changed is the manner in which CM activities are performed. These changes derive from many sources – instead of pencil and paper and large file cabinets with voluminous manila folder, we now use computers and specialized CM applications for maintain and tracking iterations of files, preparing and tracking configuration change requests (ECP, TPR, DR, TIR, etc.), and automations of various other activities. But performing a build is not a CM activity; it is merely a task that is often assigned to the CM specialist, much like washing cake pans is not a function of baking, but is often assigned to the junior baker.

Joe,
You said [quote]I feel that since this activity has historically been the responsibility of the CM person hence it has become part of the duties of CM.[/quote] Since when? Only in recent history has it been a "part of the duties of CM." I would add that there is a far cry from "duties of CM" (which I previously referred to as "task(s) often assigned to the CM Specialist") and a part of the function of the CM discipline.

As to your query [quote]Where in this oath does it say anything about giving flu shots?[/quote] You're right, it doesn't say anything about "giving flu shots." But, the fact that a pharmacist gives flu shots doesn't make it a pharmaceutical function. If it did, then all nurses would have to be pharmacists and all pharmacists would give flu shots. It is merely a task that the drugstore assigns to the pharmacist. That simply makes it a part of the store's function of customer service. Does that mean the nurse is doing a pharmaceutical function. In fact, until relatively recently, pharmacies did not offer in house flu shots.

For your second question [quote]Where in here does it say they are supposed to warn you of drug interactions?[/quote] I offer the following from the oath you presented: [quote]I will consider the welfare of humanity and relief of suffering my primary concerns.[/quote]and[quote]I will apply my knowledge, experience, and skills to the best of my ability to assure optimal outcomes for my patients.[/quote]Not informing us of a drug interaction could hardly be construed as "consider(ing) the welface" or "relief of suffering." Also, not informing us of a drug interaction is not likely to "assure optimal outcomes" for the patient."

In closing you said[quote]Builds are a function of CM, why, because it is expected of us, plain and simple, right or wrong, its the way it is.[/quote}I would add that I never said it wouldn't, couldn't, or shouldn't be a task performed by the CM person. In fact, if you had said "Builds are a task often (or usually or best) performed by the CM Specialist," then I would have no argument. I am simply saying that when that person does the build, they are not performing a CM function, they are simply a CM person performing a production line task (for lack of a better phrase). That does not make it a CM function any more than giving out lollipops is a function of dentistry. It's just something that the CM Specialist (often but NOT ALWAYS) does.

Most of the time the CM Specialist does it because of cost savings (as in salary of an additional person as build engineer).
Sometimes it's because the CM person wants to do it (many think it's fun and satisfying).
Other times its a practical arrangement for the environment (as in size and relative simplicity of the product and project.
And, probably on a few occasions it's because some CM Specialist wants to claim it as a CM function to enhance their career. In other words, taking on builds as a CM function and being the lead on a build team (who can then call themselves CM Specialists), allow him to claim supervisory positon over a number of CM specialists.

Let me point out that by your definition of build as a CM function, anyone who performs a build is, by that same definition, a CM Specialist. Let's be honest, many who do builds could maybe spell "CM" if you removed 24 letters of the alphabet and gave them two tries. Fact is, you don't have to know a thing about CM to perform builds. Fact is, I as the CM Specialist can give the build package to the designated build engineer to perform the build. Fact is, sometimes it is best to have builds performed by an expert in the product type rather than the CM Specialist (especially true in complex database schemas, hardware, networks).

Simply making a statement, as you did at the bottom of your last post, plain and simple, right or wrong, does not make it true.

I'm with Billy on this (as I'm sure you both know already). I expanded on this last year in a blog post.
http://blog.principia-it.co.uk/2011/06/28/why-youre-wrong/

I just remembered one more thing.

The argument that "CM Specialist do builds; therefore, build is a function of CM" reminds me of an incident about #%#%$ years ago. When in college, I was working on a construction job one summer. One day a new guy, John, showed up.

Henry, an old friend of his, after the mutual greetings, asked, "I haven't seen you since Christmas. What you been doing?"
John replied, "I've been over at Washington City carpentering."
"Carpentering?"
"Yeah," said John. "Well, not really carpentering, but I was helping get the boards off the trucks."

Billy:

Hmm. I see where you're coming from with the Release Management argument, but I think release management is a much broader discipline than the one you characterise here.

To me, release management (RM) is the discipline that plans, coordinates and delivers releasable configuration items into a production environment (or to clients). It is not responsible for the construction of, or the verification of, the releasable CI (RCI), but it is responsible for defining and validating (quality controlling) the content of that RCI.

When I say RM are responsible for validating the content of the RCI, I do not mean they are responsible for [i]performing[/i] the validation (that's for testing and QA), but they are responsible for ensuring this validation is done and recorded to a satisfactory standard.

CM are responsible for the accurate curation of the RCI, but have no direct responsibility for validating the functionality of the RCI.

RM are responsible for signing off on the functional content of the RCI (based on evidential results provided by testing and QA), CM are responsible for verifying the content of the RCI and ensuring all appropriate records associated with the progress of the RCI through the release process are maintained and available.

The difference between the validation performed by testing/QA and the sign-off by RM is that RM may be coordinating many individual Testing/QA activities for a single RCI.

--------

For clarity, it is important to understand I am defining [i]roles[/i] here. It is generally acceptable, and often the case, that one person will fill all of these roles; build, release, and configuration management. It is this conflation of role with 'job' that causes this confusion. (An important caveat to one person filling all roles is that one must be careful in some environments to maintain a separation of responsibilities to meet legislative requirements.)

(As an aside, I've started [early days, but it's already ahead of the old Book of Knowledge stuff] putting together a wiki based around my own breakdown of these ideas, but being a wiki http://wiki.itslm.com it may not end up that way :), I encourage everyone to dive in and make it their own.)

Things a release manager does that a configuration manager should not:
[ol]
[li]Marshal resources for deployment, including but not limited to:
[ol]
[li]Coordinate teams toward a specific release (most obvious for larger projects where many different teams are contributing, including development [if needed to assist in deployment -- *shudder*], deployment/operations team, infrastructure, administrators, etc.)[/li]
[li]formulating the release plan (the 'what we do on release day' plan, rather than the overall release plan, maybe 'deployment plan', but that seems to parochial as large releases involve much more than deployment?)[/li]
[li]formulating the roll-back plan[/li]
[li]ensuring all appropriate personnel are available at appropriate times[/li]
[/ol]
[/li]
[li]Maintain and drive the release plan (alongside the project plan(s))[/li]
[li]Ensure appropriate certification for each releasable configuration item (note, the CM person ensures that these certificates are retained and related to the RCI, but does not have any responsibility for their production, or, where CI are obtained externally, acquisition).
[/li]
[/ol]
It may be that the CM function can (or even should) prevent a RCI from progressing unless appropriate certification is available, but I strongly oppose the idea that the CM function has any responsibility for acquiring it -- this is a function of release management as part of that role's responsibility for marshalling RCI.

Often I (as the project CM person) have played the RM role, especially for deployments into test environments where these are often automated (or semi-automated) as part of a CI build environment (where I play the 'build manager' role :)), but just because I do these things does not make them part of the CM function any more than doing the build manager things makes those part of the CM function.

Release management is more akin to a focussed project management role, dealing solely with the delivery of the project from the development team to the operations team. It is possible that one could define away the RM role as I perceive it (shifting these things off to project management, for example), and that would be fine, but if the RM role is reduced to the extent it becomes just a specialised view of the CM function then it becomes redundant and we can drop if from our vocabulary (perhaps we call it RCM, release configuration management, in much the same way that SCM is a specialisation of the more general CM :dry:).

Bottom-line, it seems to me there are too many things the Release Management role does that do not fall under the four CM disciplines for them to be subsumed into the CM function.

To my mind, this is much the same situation we have with build management. Sure, the RM function uses (or in some organisation encompasses/reproduces) the CM disciplines, but I don't see how this makes release management a part of the CM function any more than it makes build management a part of the CM function.

There are more, but these hopefully help to clarify my position a little.

Bob,
What we (with the job title "CM Specialist") do every day does not define the discipline. If it did, then we could say that the Accounting discipline included paying the bills because in some companies that is one of the duties is assigned to a person with the job title "Accountant."

If doing a briefing or some other informative talk, it might be fair to say that "in some organizations the CM Specialist does builds." As Mark pointed out in another venue, it is folly to define a discipline by all the things done by a person with a job title.

I really think the problem here is one of confusing "function of the discipline" with "other duties as assigned to (or assumed by) the discipline expert."

Let me also point out that your list does not address identification, configuration control, configuration status accounting or verification of requirements and specifications, designs, or test materials that are part of a product under configuration management. It sounds like a view strictly from within the code development shop.

Billy and Mark,

I agree that your arguments have a lot of validity and Mark after re-reading your blog about why you feel Bob's approach is plain ole wrong, I have to wonder if there is a chance at a middle ground. Or are we simply so far apart on this topic there is no chance at reconciling. CM is fractured enough for other reasons, another schism could very well put our field in even more jeopardy than it is already in.

I can't speak for Bob, but I can tell you two reasons why I prefer his model of CM, which includes the four activities, which I feel we all agree are the basis for any CM discipline It fits closely with what I have done as a CM person and it fits with what I feel is a more modern view, ie I can explain this much easier than the four funtions and still get my audiences to understand. The second reason is that CM folks tend to grasp the larger picture than others in the IT Discipline even Project Managers. Since I feel with have this expanded view, who better to be involved in those areas than the ones who actually do the work.

Regards,

Joe

Gentlemen, it may be beneficial to all concerned (and perhaps especially any bystanders/observers) if we had a more interactive debate.

Perhaps, myself and Billy on the one hand, and Bob and Joe on the other? I would certainly enjoy such a debate.

I'm content for us to follow whatever debate format is deemed appropriate. As for forum, again, I'll go with whatever people prefer (and given that I'm the odd man out -- being the only non-US participant -- I'll forego a night's sleep to take part). With Bob's promotional skills I think we can attract a reasonable audience.

Your thoughts?

With respect to Mr. Falkowitz, the only place I MIGHT disagree is where he says "scope," and my POSSIBLE disagreement depends on what he means by the term. For example, he might mean anything from the scope of detailed duties (keeping records, sweeping floors and such) or to the scope of a given project (within the coding shop, across the software life cycle) or even the scope of application of CM principles (to software, to computer hardware, to networks, to ships, tanks and airplanes, or even to a company's organization structure).

As to the debate idea, I applaud it but would not be able to participate except intermittently. The only reason I can contribute the time as of now is due to a lull in work activities. That may change momentarily.

Joe,
I noticed several LinkedIn groups for Configuration Management. Could you give us the link for the one you referenced with the Robert Falkowitz quote?
Thanks,
Billy

Mark,
Let me ponder your suggestion. First thing for me is to figure out the definition of term in context of "debate." I always thought debate's what you use to catch de fish.

Hi everyone,

change control is one of the big four functions (defined in almost any related standard or framework) and it is our job to see that change control happens. The Change Control board (CCB) is usually the entity that is responsible for running the change control process and if you follow the ITIL v3 framework, the Change Advisory Board (CAB) is the group of subject matter experts who can tell you the downstream impact of a change. While the big four (configuration identification, status accounting, change control, configuration audit) are completely correct - I think people have an easier time understanding CM as source code management, build engineering, change control, release management and deployment.

Bob Aiello
Editor in Chief

[quote="bradapp" post=103261]I can understand wanting to come up with descriptions people have an easier time understanding. I am curious however as to why you chose "[i]source code management[/i]" over "[i]version control[/i]"[/quote]
Somebody else who doesn't like concept hijacking! Hooray!

I fully agree: [i]source code management[/i] brings nothing that wouldn't be in [i]version control[/i] (or in fact, even in [i]revision control[/i].)

This is clear when git users want to stress its 'distributed' aspects, and switch without a hunch to [i]dvcs[/i].

As you all know, I have been fighting against a similar unjustified concept hijacking by the CM community, with their (your...) using SCM for nothing more than what they (you) already termed CM.

Maybe the start of this confusion was the excellent eponymous book by Wayne Babich in 1986. Clearly, this was a book about CM [i]applied[/i] to software development, possibly with some support from the revision/version control tools available at that time, and maybe even (I do not have the book at hand, and have not read it for 15 years) with an agenda to enhance this support.

Anyway, in my, necessarily limited, experience, the only tool which radically took the road of making of software configuration management a reality, with a difference significant enough to justify a new name, was (base) ClearCase.

It did that precisely by answering the original question of this thread, and bringing to the front [i]build management[/i].

Now, this changed everything! Or rather, could have changed everything, if it had been acknowledged. Build management à la clearmake did provide identification of universal configuration objects (not only sources!), as part of their 'versioning', i.e. as members of families. It did produce objective data that allowed for automatic sanity checking (auditing) and a support for reporting.

In short, it made at once all four [i]activities[/i] of traditional CM, as well as the infamous CCB, obsolete, and subsumed everything under the single build management.
The remaining work was to write and maintain correct makefiles, and possibly script tools for specific reporting...

This revolution was never completed (still lacking in many ways), and was not followed up in a timely manner when laptops, then Java came in the picture.
It was however never surpassed, so that I believe it is still relevant to take software development out of the dead ends and of the mess into which it has been driven for the past decade.

Marc

Hi Bill,

[quote="bglangston" post=103263]Brad,
At the risk of diverging from the subject of the thread...

You said:[quote]None of these ALM tools seem to be capable of doing that (e.g., creating and managing a baseline that crosses multiple types of lifecycle artifacts)...[/quote]Maybe I don't understand what you mean, but I'm thinking that such tools as Dimensions CM, the ClearCase/ClearQuest set, MKS, Razor and a couple of others have that capability. Dimensions, for example, does provide for gathering multiple types of artifacts into a baseline.
[/quote]

Does it support that when the multiple artifact-types in question each use a different tool+repository of the "ALM system" to hold those artifacts? For example, if the requirements, tests, models, and code are each in 4 different repositories, each managed by a different (sub)product (e.g., a reqts-mgmt tool, a test-mgmt tool, a code-mgmt tool, etc.)? So I could give a single query or command and get the set of each artifacts and their artifact versions that participated in that baseline?

Similarly, if one needed to create a new branch/stream of development (to support parallel development efforts), then the ALM "system" lets me create a single entity with the specified name, and allows that name to represent the "stream" of work/changes across all artifact-types and their corresponding repositories/tools?

Thanks, Brad.

I'm guessing that, as you say, none currently would do that. There are a couple of them that allow plug-ins of file management systems of different types. I would see inter-tool licensing as a major obstacle, although a couple of the ALM breed do allow a few plug-ins. (As an example, Dimensions has a plug-in for Eclipse.) But for a company to produce a tool that would accommodate ALL the possibilities would probably be considered cost prohibitive. Shame that!

As I'm sure you know, most of them will HOLD files of virtually any type but generating a fully integrated product of multiple types of files from a single engine is a pretty tall order.