Which is preferable—Build/Release role or SCM admin role

My advice is thus: if you can, keep away from a company in which this distinction is made. If you cannot, it is your job to change it.

We live times of crisis in terms of SCM (btw, SC standing for Source Code in this acronym is an Orwellian joke, telling in itself of the crisis I am mentioning).

This is a side-effect of the explosion of the Internet:

1. the continuity of the development of SCM got broken: any wisdom got lost
2. software suddenly became a juicy market governed by short term concerns
3. There is a third factor, and it is that old CM and established vendors retracted into defensive politics, patting established organizations within companies in the back, thus giving rise to entrenched bureaucracies.

Marc

asav wrote: "The distinction may be insane - but is dependent on any given company's implementation of Configuration Management. The fact that the Source Code admin and Build Engineer functions have been separated is problematic but increasingly common."

I think we need to be clear what is ment by "Admin". There is the tool admin - which seems to be what the original poster is refering too and then there is more of the "Librarian", "Release" or maybe a "Process" role which seems to be getting muddled in.

I find the separation of the roles very benificial particually in a large setup. The tool admin is concerned with a lot of IT issues like backups and storage allocation and may be best done in the IT department and is likely to be supporting many projects (100s or more in a large centralized setup - Subversion over http: is often done this way).

The release management role can be done by the build manager or librarian or by a separate quality or project support organization. The librarian role could again also be the build manager or might be a separate role in a large project who also does document and other information and data management.

At the oposite extreem the build manager needs to know a lot about the project they are working for and work very closely with it or even as part of the project team.

Obviously these people all need to liaise. But you don't expect your cook to install a new stove - so why do you expect your build manager to install the CM tool?

As baynes indicated, sometimes separation of the roles is beneficial. This is especially true when speaking of Configuration Management. For example, a common view (relatively common anyway) is that build and release are functions of CM. Actually, they are not but are tasks/jobs often assigned to the CM specialist. Unfortunately, because of the assignment, many have come to think/assume them to be part of CM duties or functions.

Regrettably, many think of tool administration in the same way. For many/most CM tools, it is desireable to have a CM specialist who can also function as the tool admin. There are advantages, but that does not make tool administration a function of the CM discipline. In some organizations, the CM specialist does the design work for the repositories, work flows, etc. and feeds this work to the tool admin person, who sets it all up on the tool. The Rational tools are, in my experience, almost always this arrangement because of the "system administration" skills needed to administer CQ and CC.

So to more directly address your question (dilemma), if you enjoy doing builds and releases and associated set up work in the build tools, stay with that. If you want to learn to administer CM tools (in other words, become a system administrator type), then move to that. The third option is to become a specialist in the CM discipline.

Good luck in whichever you choose.

I think what some have failed to see or maybe even care to admit is that the CM role has evolved over the years. Back in the really old days, the CM folks did everything by paper and backups, there where no real "CM" tools on the market.

When CM tools started to appear, it was natural for the CM folks to administer these "new" command line based tools that handled CM Functions. In addition you where probably expected to install the tools and train people. Now training and installing software is not to be found in any of the 4 activities of CM.

Mr. Baynes I disagree that the cook shouldn't install the stove, I would prefer they do it over the waitress who waits tables or the dishwasher who washes the dishes.

Now with separation or segregation of duties it was found that developers should not do all of their builds, the ones for system, uat, production, etc. So who did it logically fall to, well QC or QA didn't have the expertise, so it fell on the CM person to do the builds and sometimes the releases. Again this was the evolution of the field, it just happened. Right or wrong its where we are at today.

Does that make it right? That can't be answered. In some shops CM folks wear many hats, right or wrong its expected. So just by default many of these things have fallen on us to do.

Regards,

Joe

Joe,
I think I know what you are driving at, but the problem I have with what you said stems from semantics.

The CM role has not evolved over the years. The duties of the person assigned as the CM Specialist have evolved over the years, but not the duties of the CM role. We might say, "In the old days, Fred was our CM specialist; now he is also the build engineer." Unfortunately, we are prone to say more simply (but highly inaccurately), "CM does our builds." Actually, the CM role is still planning and ensuring that proper identification, configuration change management, status accounting and auditing are conducted in an optimum fashion for all concerned (although "optimum" is not a CM requirement, it is practical).

No, no, a thousand times no. CM does not do anything. CM is a discipline, a set of principles.

And the more we are haphazard in the way we word things, the more we will suffer at the hands of confusion.

As to who should install the stove, why would the cook be preferable to the waitress or dishwasher? Is it because the cook actually uses the stove? What qualification does that give him to connect the gas-line or wiring? Now if we were talking about the layout of the burners, grills and ovens on that stove, that is another matter. In fact, I'd rather have the cook do that over the stove installer.

Similarly, it often may be desireable, as I said above, to have the CM specialist do the CM tool admin. This is not because he/she is best at it, but because it avoids possilbe conflicts between the technical toolie and the CM specialist. On the other hand, if there is a good relationship between the toolie and the CM specialist, then by all means let the toolie do the admin work.

But if the CM specialist is adept at doing the tool admin work, then assign him/her the duties. That does not make it a CM role or even a part of the CM specialist's role. In means that Fred now has the tool admin role and the CM specialist role. Again if that were to happen, no doubt someone would get around to saying, "Go get CM to install your user permissions on the tool."

In other words, I agree with what I think you are saying for the most part. But CM folks don't wear many hats; folks wear many hats, among them that of CM specialist.

Now, go have a Happy New Year.

No, sorry, can't say that. "Happy" would be a documented requirement. "New" would require a documented design. That's too waterfallish. Since documentation is secondary, go have a "Year!"