How to make a build (java) as “CM-independent” as possible? (CM=Configuration Manager)

Question

I have been thinking of making one of the project builds I handle, as "independent" of me(CM)as I possibly can. By this I dont just mean automation via scripts/tools - although it definitely includes it. This is a project subject to much chaos and so "total" automation would not be realistic.

Here is what I'm aiming for:

Anybody should be able to do the build (with some automation and a bit of documentation/guidelines) - for instance - a newbie CM, or even a developer with no CM experience.

My first thoughts are to achieve this by:

1. Nailing the Build request process (via build forms which capture ALL details required for the build so that nothing falls down the cracks just because its in someone's head)

2. Simplifying the build steps so that they can be captured in a simple documentation as a sequence of commands - a trained monkey should be able to run with the build (well.. not hurling insults but - you get the idea :-) )

3. Using the tool's features to the hilt (read ANT,SVN) such that the potential issues are caught well in advance and also help provide better alerts in case of failures/issues.

4. Having the freedom to fall ill or take those occasional holidays without the project manager getting panic attacks everytime i mention a couple of days' off. :-)

I'd be glad to have some thoughts and ideas to help me in this direction. Thanks all!

Answer 1

At Urbancode, we refer to this as the "Bob the Builder" anti-pattern. The good news is that Bob (you) wants to get out of the loop. When the build guy can't go on vacation or get sick without parts of the process grinding to a halt, there really is an unacceptable problem. If I'm a betting man, as you start the process of simplifying the process down to "trained monkey" levels, you'll wonder why you're spending your time doing this rote stuff when you're smart and could actually be adding value somewhere.

The symptoms of "Bob the Builder" syndrome in our book:

1. All requests for builds, or builds of a certain type, go through an individual or small team.
2. Response to these build requests is annoyingly slow for developers. If the build team is at lunch, they wait hours.
3. Bob, or the team of Bobs, spend a significant percentage of their time doing rote tasks.
4. The Bobs going home for the day, going to lunch, going on vacation, or getting sick impede the ability of the team to get things done.

We tell our AnthillPro customers to push all of this kind of stuff into their automation. Having two build types that use different machines, different build numbers, etc shouldn't be a problem.

The first step is to dumb down the process. Drive as much complexity out as possible so that you can get down to the "trained monkey" process. Once you have something approaching that, replacing the monkey with a computer is pretty easy.

I'd give more specific advice, but I don't think you've told us where the complexity comes from, other than chaos. Sometimes in this situation you need to attack chaotic and bad practices. Are you doing builds that are "This baseline in source code and those two files and these three files?" That would be tricky and probably need a CMer in the loop. Find a way to forbid it. Replacing that with "Create a branch, and make specific changes to that branch" makes constructing the build doable by that monkey.

You should be able to argue for those changes as high risk. Even though you are good, you will have bad days and want to take human error out of the equation as much as possible. At the same time, if you're shooting for faster response to the developers and self service (which presumably development and management want) some things will need to be made automateable / monkeyable.

Having better forms can be good in the interim, and using your tools well is always good but I would attack the the "trained monkey" problem pretty aggressively. Anything that can't be done by a trained monkey (or a computer) should be a candidate for leaving the process. Once you have it down to "trained monkey" status, get your build automation in place so neither you nor the developers need to be monkeys. That changes your role from "Bob the Builder" to "Bob the Build System Owner".

Answer 2

Simplifying the build steps so that they can be captured in a simple documentation as a sequence of commands - a trained monkey should be able to run with the build (well.. not hurling insults but - you get the idea :-) )

If that is possible than it should be possible to run the build in one step via a script (mayy it be an ant, bash, maven or whatever script). That should be the goal, so basically anybody can do the build.

Answer 3

The goal of developing a build process should be this:

1. Start with an empty directory anywhere (tabula rasa, if you will)
2. Make sure a very small tools of basic tools is intalled (for me that's usually Java + Maven + SVN command line client)
3. Check out a single directory from your SVN/CVS/...
4. Start a single command (and that means something that doesn't have 25 parameters)
5. Wait (possibly quite a while)
6. Have your complete build

If you can't do that, then your build process is still not good enough.

If you think that you can't achieve it, then describe in detail which actions you need to do in addition to that list are not possible to do by a turing-complete machine.

Usually there isn't such a point. It's only the missing tools/know-how/motivation. I, personally, found out that it's easier to do this, than to describe why it can't be done.

Good luck.