Your Build Script Is In Production Use Everyday---By Your Developers!
Yesterday was my last day at my current client (that I started 163 days ago).
As I reflect back I couldn't help but notice something odd: each developer uses a different set of Ant targets in their daily routine. The fun begins when something goes wrong:
Berlin, I just did an ant update, and the server wouldn't start now. Do you know why?
Sorry, I never do ant update. I always do ant get_all. Ask Ninju.
Ninju, Ninju, Help!
Oh, you are in the Build directory. You should be running from the dev directory. Just do an ant from there.
But wouldn't that take, what, like two hours?
You can run ant quick_compile then. That'll skip the part that takes too long.
Thank you!
(Later) Zhicheng, Ninju told me to do an ant quick_compile from dev, but it still doesn't work!
No, ant quick_compile deletes a directory that you need. Do an ant gen to get it back.
OK. (Ran ant gen.) No, it still doesn't work. Hey Cathy, do you know anything about this?
They send out an email yesterday about the latest changes to the build scripts. There is a batch file that you need to run only once.
Could you forward me that email?
Sure.
(Reading email) Ahh, I need to go to dev/config/versioning and run version_gen.bat. That fixed it. Thanks everybody.
We wouldn't dream of inflicting such pain and confusion on the users of the software we are building. Yet we do it to ourselves. We are users too. We are users of the build scripts for the project we work on. If the build script is not right, we all lose productivity.
The build script is in production use everyday. Treat it accordingly.
Re: Your Build Script Is In Production Use Everyday---By Your Developers!
We do use IDEs most of the time. The Ant build script comes in only when we want to commit the code.
Better documentation definitely would have helped with the build script.
Treating the build script as a regular work product and dedicate some man-hours to do some proper design, maintenace, refactoring, and general cruft reduction would have been better.
Re: Your Build Script Is In Production Use Everyday---By Your Developers!
The other part of this is getting a smart programmer on your team who really understands how to put together an automated development environment, has a deep understanding of version control, knows a tool like Ant or Maven, etc... We don't have enough people like this.
I often see cases where management assigns "menial" work like version control and the build tools to the LEAST qualified programmers, because they want the best programmers to focus on the application logic. Ugh.
Re: Your Build Script Is In Production Use Everyday---By Your Developers!
I tend not to give developers that much choice. :) There are three standard targets developers are told to use:
* build
* full-build
* deploy
Build does a build from a reasonable clean slate, runs unit tests, produces distributables, etc.
Full-build does it from an even cleaner slate, including blowing away third-party jars and fetching them again. The full-build also does more enhanced analytics (such as code coverage of tests). Full-build can be run by developers, and should be periodically, but is mainly intended for use by the CruiseControl server.
Deploy does that; it also does a 'build', but skips the testing.
Note that the use of a controlled environment (the CruiseControl server) means that you can readily decide if a problem is local to the developer or not.
Re: Your Build Script Is In Production Use Everyday---By Your Developers!
I agree with Robert. In this case, less is better. It's all a matter of attitude, however (I happen to prefer a directing approach whenever possible).
I think the same issues apply to APIs. Many times we require programmers to understand too much detail. We think flexibility is so cool, that we ignore the complexity that comes with it. Many times the flexibility is never taken advantage of, but we still accept the cost of the complexity.