views:

102

answers:

4

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!

+1  A: 

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.

boutta
A: 

Let me clarify - I dont mean automation of the "compilation" or the build step itself. I already have a build script(ANT) that does this.

In our case, the automated, daily builds used for testing/dev environments differ from the managed/controlled builds (production quality) performed by a Configuration/Build manager in that these builds are tagged/documented/ besides being run on a different server (dedicated for builds) and hence has different steps to help us track the build neatly with the required naming conventions and such stuff.

I am looking for ideas to minimize ways to ensure that these steps are still incorporated while minimizing the dependency on the build/configuration manager herself/himself for any special skill/knowledge in CM for the same. In case of a single person handling all the project builds, this can be quite a help.

Please keep the ideas coming..

thanx!

Critical Skill
Clarifications are better put by adding to the end of your question. It's more obvious that it's a clarification and not someone else's answer.
Eddie
Everything you said can be done via a script, except for the documentation part, but you could put this into a wiki with a clear pattern and thus make it easy to reproduce for anybody new to the task.
boutta
+2  A: 
EricMinick
A: 

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.

Joachim Sauer