Ant Best Practices: Use Ant as the Least Common Denominator
• Julian Simpson
We're back to the best practices this weekend with 12 of 15: Use Ant as the Least Common Denominator. What are we talking about? The answer is here.
What does the common denominator mean? There's generally a conflict around this on software projects. I'll explain:
The developer wants to write code. Fair enough. That's kind of their job. IDE's give them an immense productivity boost in doing that job. If she needs to switch to another application, the developer will lose focus. So there's a booming IDE plugin market. So developers will tend to avoid vendor tools in favour of IDE plugins: version control plugins, database plugins, tracking system plugins, etc. By doing so they can become very, very effective.
The release manager and his superiors have a different angle on this: they want to know that the code is deployable. To be deployable, you have to be able to build it. So they have Ant, or some other build tool. That way they know that the code will consistently build and pass unit tests.
Developers (like most people) don't tend to like impediments to their productivity. Release managers aren't fond of code that they can't metamorphose into a working system whenever they feel like it. So developers would rather build all the code using an IDE than have to switch to a command line and build the code. Most release managers don't want a dependency on a tool that doesn't really address their needs. It can also be difficult to automate IDE builds.
So the conflict is that each camp has valid reasons for not liking the tools of the other. Which way do you tip the scales? Projects that aren't constrained by developer productivity (i.e. maybe you have a shortage of testers) should be setting clear guidelines about the build tool. On the other hand, I'd get the kid gloves out if the developers were under pressure to deliver. Eric M. Burke suggests that you at least make sure that:
- There's an Ant build that the developers can use
- They run it before checking in
- They can use whatever tool they like while until checkin time.
That way, you know that you can reproduce the software later; that Bob didn't check in code that builds against the development version of a library. The regular checkpoint of the pre-checkin Ant build will allow some flexibility for the developers.
It works for me.