The support and consulting teams at Urbancode are often asked when to attempt to reuse configuration and when not to. If two projects can use the exact same job for build or deployments, the same workflow definitions or same life cycle models it's pretty obvious that reusing the configuration is beneficial.

However, most teams find that there are some variations between their projects. Perhaps the build scripts need to call another target, or parameters into steps need to change. Usually, this isn't an impediment to reuse. The build target can be parameterized and the variations between projects can be encoded as project or workflow properties. Generally this level of reuse where all the steps are executed in the same order and a value here and there is adjusted per project works fine.

Where things start getting difficult is when one project needs an extra step. A job can be stretched to meet this need as well through step precondition rules that check property values. We would recommend treating this as a red flag though. Reuse of configuration is not an end in itself, it is a tool for making your life easier. As often as not, your life would be easier, and your AnthillPro easier to understand and maintain if you simply copied the existing job, added the additional step and had two jobs.

For lifecycle models, as long as two projects as similar and share the same statuses, reuse should be possible. It helps to use reasonably generic artifact set names like "application", "web" or "lib" rather than overly specific names like "Order Dll" or "Sales Ear". If some projects don't use all the artifact sets, that's OK as long as the list stays manageably short.

The good news is that if the team finds that they have pushed reuse to far, it's pretty easy to unwind. Clone the existing job and make modifications to it. Create a new lifecycle model and migrate the project to it.

Teams that push reuse the furthest with success have balanced having Anthill adjust the reused component to the project and standardizing the projects so that they are all built or deployed in the same way. Standardizing the projects often requires cooperation from more people, but has benefits outside of AnthillPro.

During a roll-out we often error on the side of having separate configuration for each project initially. We then look and see where we have duplication and factor it out into library jobs. Where we know two projects are identical or close to identical, we can start with shared configuration, but separate configuration through copying is often easier at first while shared configuration is more maintainable over the long run. How far have you taken reuse? Have you pushed it too far?

If you need a build of some sort, does protocol require you to ask someone to run it? Do you have to wait until the build team Bob is back from lunch in order to perform a build? Do you have to wait for one of a few people who actually know how to do a QA deployment in order to deploy to QA? If so, then you already know Bob the Builder.

This post explores the Bob the Builder Anti-Pattern and offers a strategy for correcting it.

Read more...

We find that many teams have build farms comprised of various hardware and want to optimize their builds to run differently based on the hardware selected at runtime. A classic case is where the build tool allows for the selection of compilation threads.

Read more...