None. The distinction is insane.
I know: I am currently working as Build Engineer only, and I don't believe it makes sense.
Half of my time is spent making requests which takes me more time it would to do the work.
Marc
Which is preferable—Build/Release role or SCM admin role
I am new in overall field of Build and Release.
I have installer experience and currently working on build tool like Buildforge for carrying out daily builds and further creating installers using installshield.
In my organisation we have a separate group SCM which comes under our team BRT but have different responsibility to manage SCM tool. We use clearcase and clearquest in our organisation.
I have been offered to work in IBM Rational admin role for build and release. I am confused between admin task and build engineer job to create build script for different project and managing build tool such like build forge. In SCM admin task, we have responsiblity like project creation,VOB Migration,multisite,Managing rational server and other task related to SCM admin.
Can any one suggest scope of what role is more preferable?
Input from the people on this forum would be really valueable for me.
Looking forward for your suggestion.
13 Answers
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.
anks - I guess you have a few factors to consider here.
CC and CQ are complex tools with a steep learning curve. In many dev shops they also need a good deal of maintenance and hand-holding (fixing evil twins/hijacked files, trigger maintenance, VOB locking, MS packet loss, workflow tweaking). If you're on a greenfield site, that may work to your advantage, as you might have an opportunity to help build these systems from the ground up - building wrappers, defining process etc. But often, Rational admin roles are just that.
You may want to consider whether you actually want to pick up these Rational toolset skills. They're transferable, for sure, and still valuable within the market place. If you come from a background in tool development you may find that your opportunities to script, create and develop new toolsets may be more limited in an admin role. But that is entirely dependent on your company and their take on the remit of the 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
I think there may also be a little intransigence across the marketplace (and I count myself wholly in that group).
10 years ago I was in a CM Engineer role that included Source Code Management, Build Management and maybe Release Management responsibilities as part of one entity, which would have been relatively standard at the time. And at that time, I was using CC, CQ/DDTs, Clearmake and some install wrapper which were all relatively integrated.
That model still exists, but less so, today. To play devil's advocate for a moment, and to address the OPs question, why should I necessarily have responsibility for, and be an expert in, say Subversion, ant, Installshield, some other build or deployment wrapper, some open source framework, all of which fall under the SCM umbrella. SVN/git/Mercurial etc require a good deal less overhead than most of the tools supplied by the 'established organizations' you mention and provide decent functionality pretty much out of the box.
My frustration lies more with the missapropration of the function of Configuration Management. SCM as Source Code Management is a fashion, a whim that splits out the functions of Configuration Management and compartmentalises each discpline - which is only an issue when 'the other guy' holds up development, or you think you could do his job better than him.
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?
[b]asav wrote: "I think there may also be a little intransigence across the marketplace (and I count myself wholly in that group)."
Er... intransigence? Not sure what you mean. I probably look intransigent as well (people would every now and then tell me arrogant), but I would stand for it: I try to make clear points and avoid politics. It is very hard to engage any sort of discussion: everybody wants to talk, and nobody to listen; everybody wants to shut the others up, and is all too fast to call them names, such as 'arrogant'. Arrogance is just the end of discussion, often before it ever started. But being pragmatic, you cannot discuss with everybody: you have to pick the ones with whom there may be some kind of resonance.
"why should I necessarily have responsibility for, and be an expert in, say Subversion, ant, Installshield, some other build or deployment wrapper, some open source framework, all of which fall under the SCM umbrella."
Let's make it clear: you cannot be an expert at everything. So what? This doesn't mean that you should dump the responsibilities to people with whom you have no communications. We are all forced to make decisions in a context of bounded rationality and uncertainty. If you don't know, how can you assert the others know? You cannot.
SVN/git/Mercurial etc require a good deal less overhead than most of the tools supplied by the 'established organizations' you mention and provide decent functionality pretty much out of the box.
Maybe, but beside the point. I'll continue later. An other day.
Merry Christmas!
Marc
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.
As usual....it depends :S
Each company\organization has its own definitions and tasks for roles like librarian, admin, buildmanager and so on.
What I would advice (from my own experience) is
- try to get a good overview of the different tasks and roles
- find out for yourself what you really would like to do
- also look at the future: learning something new might be fun and great now, but will you still like it if the job becomes predictable and repeating
- what are potential grow paths in the future within your organization
In the companies I've worked so far (large companies) we had a clear separation of the admin roles (vob management, viewservers, network, multisite etc) and configuration management.
Personally I like the CM part more, as you are working in the projects \ contribute to the products your company is making.
Also some strategic topics are part of the job, like how to deal with parallel development.
As admin, you're more in a supporting role, and part of an IT department. Strategics as admin are more related to server-extension and planning of upgrades of your toolset. Also interesting, but different from the configuration managers role.
So far my $0.02
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 wrote: "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."
Seldom enough to be noted: I agree with this.
In fact, I believe that the cook metaphor is not appropriate and dangerous.
I believe that software can only be open, i.e. cannot be split according to a predefined scheme, necessarily bound to existing, i.e. old knowledge. This has to do with the fact that the value of software is always bound to the external surface, and not to the internal volume, of the sphere of the achievable. What has once been achieved, anywhere, should be reproducible at no cost by anybody. If this is not realized, we are not speaking of software, but of some kind of hardware.
Software is always on the edge, be it leading or bleeding.
And the way I see it, it can only be based on Build Management.
Marc
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!"
Billy,
You said:
"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."
I think we have agreement here, like many things over time they just become accepted right or wrong. My approach has always been that I will wear those hats out of necessity, because no one else wants to do it.
Regards,
Joe
Anks,
I had experience in Installshield before I got into ClearCase/ClearQuest/Build administration. But I would love to CC/CQ/build engineer/admin rather than an Installer/release admin/engineer because I love to do more on CC/CQ/Build admin side than installer. In my opinion, a ClearCase admin mostly involves in setting up/managing builds as well. So in most cases, ClearCase administration and build management cannot stay apart. But the installer automation is a different support group/release engineering. So the question is, you really want to be a release engineer/manager or an SCM specialist? As other posts says, do what you like to do in long term career.
I have never seen or experience an SCM engineer/admin just do the CM activities (unless you are a consultant)
Talking on the responsibilities, build management is considerably very little if you are comparing with the ClearCase administration. A ClearCase administrator holds a very responsible position in the company as you can imagine if the ClearCase server goes down, the company is counting on you to get back it online as the whole the process stops; If you are working with a build tool opposed to a build tool which you have written, its even negligible.
So, if you are ready to plunge in the SCM world, make sure that you get a training from Rational or have a good understanding of the system before you start the admin level duties.
or.... stay with Release management (Installer automation/release engineering etc).
Hope this helps.
Thanks,
Dani.
CMCrossroads is a TechWell community.
Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.