ClearCase/ClearQuest Administrator & Tool Developer at Advanced Technology Systems (Herndon, VA)

Javascript is currently disabled. We strongly recommend to enable it in order to optimize you experience.

Jobfox currently requires Microsoft Internet Explorer version 5.5 or later, or Mozilla 1.0 or later, or Firefox 1.0 or later, or Apple Safari 1.2 or later to run properly.
JavaScript should be enabled, and cookies must be accepted for optimum experience.

I understand that Jobfox may not work correctly with my browser - proceed anyway

View the original article here

M1033N - Software Engineer (10B) - TS/SCI at BAE Systems (San Diego, CA)

The qualified candidate will join the M1033N software team to contribute and develop significant upgrades to a complex enterprise-wide Imagery and Geospatial Intelligence System. The person filling this position will work in a multi-disciplinary team in the midst of a multi-year, multi-phase development. The large-scale development effort you will be joining will be integrating some of the latest hardware platforms and software applications with custom code to satisfy customer requirements. Candidate must be a team player with a proactive attitude and the ability to be productive in a dynamic environment. Responsibilities include:

- Initial software maintenance duties to include but not limited to performing investigations and analyses directed toward problem resolution.
- Identify and fix software problems, integrate changes into existing code, test code changes, and document those changes utilizing defined technical methods and procedures for completing engineering tasks.

View the original article here

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

tekkie wrote:
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?
I don't really agree with anybody on this thread...

The problem is probably in the question, and more precisely in the 'is' predicate.

SCM is about management, and shouldn't make sense unless it would be itself manageable. Thus it has to take responsibility for its presentation of reality: it cannot accept arguments of authority. Thus nothing is unless we want it and know why.

The special kind of sophisticated SCM I'd wish to achieve/evolve (trying to avoid the word 'build'), based on concepts taken from clearmake, would reverse the terms of the assertion: SCM is a by-product of Build Management.

I have already attempted to develop this idea, e.g. in: DO Management, or in: DO as CI, but here is a new bit of argument: identification makes only sense for stable artifacts. Unless the SCM/build tool provides a way to promote, save, and share derived objects, the only stable artifacts are (hand-produced, and thus slowly changing) 'sources'. But as soon as the life-time of DOs gets extended, it becomes possible to base the whole identification on them, and this makes much more sense than the traditional state-of-things.
This is because DOs have more intrinsic value, because they have a structure (based on dependency graphs), and because they may typically be run (they don't need to be painstakingly interpreted).

Marc

View the original article here

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

Mark,

I guess will have to agree to disagree. But keep this in mind, I say as a CM person I typically don't do that many CM activities, it is either done by developers or testers. Now they may or may not know they are doing CM things but they are. So if you look at CM activities I would go so far as to say that Developers do about 50% of all CM activities and testers about 40% and CM folks about 10% at least that's been my experience.

Regards,

Joe

View the original article here

ClearCase/ClearQuest Administrator & Tool Developer at Advanced Technology Systems (Herndon, VA)

Javascript is currently disabled. We strongly recommend to enable it in order to optimize you experience.

Jobfox currently requires Microsoft Internet Explorer version 5.5 or later, or Mozilla 1.0 or later, or Firefox 1.0 or later, or Apple Safari 1.2 or later to run properly.
JavaScript should be enabled, and cookies must be accepted for optimum experience.

I understand that Jobfox may not work correctly with my browser - proceed anyway

View the original article here

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

It can be a blend.

You mention that determining which components (and versions of those components) should be used is the job of people. That should be true, until the people decide that there are obvious rules like "Use the latest version of the logging library approved by the security team" or "Latest build of that other related project".

Once there are rules, the mundane work of actually looking up the correct version and provisioning it into the build workspace can, and should, be handled by the build system. All mundane, repetitive, rule based work should be pushed to automation if possible to free up smart, creative, and less consistent people to work on interesting things - like defining the darn rules in the first place.

I suspect the SVN folks are used to working in a straight forward environment where clear rules made it easy to offload the work to automation. If the rules aren't defineable in your environment, the first question to ask is "why?". Is it because it's hard to formally track what's approved / released / built from various teams? You can fix that. It's possible that things are genuinely hard and human intervention is required. That tends to slow things down and I try to drive it out of the process where possible.

Keep in mind that there is a difference between a build tool like Make and Ant which are compile / package tools and larger build management frameworks which handle component provisioning, etc.

View the original article here

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

Systems Support Analyst - Unix/Perl/ClearCase

IT Security Analyst (Malware Analyst) – SNORT/SourceFire - NID
I TEK Solutions  -  Tempe, AZ 85281

The Security Operations Center (SOC) is a secure, highly available environment staffed by Enterprise IT Security Analysts. The analysts monitor the health, status, and availability of security devices. In addition, they run vulnerability scans, manage...

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