Subject: Configuration Management the build system's job? - by: Udovichenko

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

View the original article here

Subject: Configuration Management the build system's job? - by: mbools

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.

View the original article here

IT Build Engineer - ClearCase, WebLogic, Oracle

IT Project Manager (Technical Delivery)
Kforce Professional Staffing, Inc.  -  Charlotte, NC

Manages a team assigned to a specific initiative inclusive of requirements gathering, high and low level design activities, development, testing and roll out activities... Responsible for creation of detailed workplan, project plan, and tracking of project...

View the original article here

Configuration Management the build system's job? - by: bglangston

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.
View the original article here

Configuration Management the build system's job? - by: baynes

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.
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
View the original article here