Build Pattern: The Captive Build Tool
•
Check your build tool into your version control system. Ideally you'd do this in a relative location to your project(s). That way you can have a go.bat or go.sh: a one line wrapper script to call the correct build tool from your project. Don't get clever. This should be the simplest script you can manage.
Once you have this set up, a new developer can be cutting (and building) code on their first day. This is a huge boost for your newbie developers. This pattern brings more love to your team because a new library doesn't mean all of your guys downing tools to add it.
I was going to call this pattern Ant Farm, but that would have been a little Java specific. We'd also need NAnt farm and Phing Pharm. So why do this? The build tool should be vanilla enough to deal with any project. If that's the case then it becomes a commodity on the developer's computers. However in this messy world it never seems to work that way. Here's why:
- Someone will have to use a new feature, which calls for everyone to upgrade the build tool
- You'll end up using a task which insists on being on the boot classpath
- One day you'll look at the build tool and find half a dozen key dependencies are residing in it.
So go with the flow. Make one canonical build tool and make it a damn good one. Put all the useful tasks in it. Yes, all of them. But with one exception. Make sure that they aren't project specific. Do you want to have to have the right version of build tool to build and test your application? No. Didn't think so.