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.
No comments:
Post a Comment