I’ve been in that boat a few times (You can have a look at a talk of mine from last year’s VA Smalltalk forum here (PDF) (Video)).
While it seems easy to define a standard way of managing code, building and deploying artefacts and such, it can be extremely hard to use that way of doing things work in a project team that has

existed for 10 or more years

lost the people who once managed all that stuff

always done it the way they do it (often without understanding why)

never enough time to change such complicated and unimportant stuff (because improvements in the process do not immediately improve the product)

So I’ve given up on the idea of giving teams a toolset for managing their code and do automatic builds. This will surely fail, even if the tool involves automatic build servers like Hudson (which is really easy to use for Smalltalk builds). Because the hardest part is not to make Hudson or any other rool run. The hardest part is to change a team’s habits in order to deliver a codebase that can be handled by the tools.

My approach is to work with a team for a while and tweak my ideas and tools individually for that team or develop new concepts and tools with the team rather than trying to tweak the team too much. It’s good to identify problems and convince people to change their work style, but you can only go a certain mileage into that direction without risking to mess up the project completely or become the esoteric clown that nobody listens to any more.

It is much better, btw., to first see what problems the team has identified and try to solve these first. Many times, these have nothing to do with Build Automation at first sight, but with lack of communication or knowledge.

Build automation is social engineering – at least in existing project teams.

Commercial Break: If you are looking for a social engineer with knowledge in Build Automation in VA Smalltalk, perform these two easy steps: