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.