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.
Related posts:
- Build Pattern: Facade Let’s face it: Build scripts can age as badly...
- Tool News, February 2010 There’s a new Hudson out. It’s got 7 bug...
- Build Pattern: Green-lit build Continuous Integration should be a highway, not a parking...
- The quest for a decent Ruby Continuous Integration tool Git has become very popular in the Ruby community....
- New CI tool: Crazy Ivan “Continuous integration should really just be a script that...
Related posts brought to you by Yet Another Related Posts Plugin.