On reading the joel test and about daily builds, a discussion with a few tech-lead friends of mine in various companies revealed that they never did daily builds or continuous integration because according to them:
- Daily builds were meant for projects following Agile practices. It does not work for the waterfall model.
- Continuous integration required automated testing which their OpenGL/OGRE/OSG type-of graphics project couldn't use, because apparently automated testing is impractical for projects where the graphics part is under (re)development.
- One of them believes that it's not necessary to have configuration management. It's just enough to follow the philosophy of it, by defining small 2-3 day tasks, perform all activities of the development cycle for each task (code, code-review, unit test, integration), deliver to integration stream and build and generate the setup.
- Even if they created scripts for the entire build and burn-to-cd process, creating automated tests were a problem because in any program you create, you can't always know what tests you'd have to run and scripting a test case for it takes up too much time and automated testing tools may not always support the specific kind of tests you might want to make.
Is daily builds and continuous integration really practical for non-agile projects? Is it meant only for test driven development? And is it really sufficient to follow the point 3 (above) kind of philosophy? I was talking to them about the build-in-one-step kind of scripted automation that Joel talks about, but they weren't willing to buy the idea.
p.s: I've been through the questions on this site about daily builds etc, but I believe this question is different.
EDIT: Point 3 should've started with "One of them believes it isn't necessary to integrate configuration mangaement with development tools"
Best Answer
Your friends are being lazy and IMO unprofessional - the world will soon pass them by.
I don't have a definitive reference handy, but daily builds were common at least as far back in the 90's, so they pre-date Agile, and the *Unified Process timeline. Any time you have more than a couple of devs, SOMEONE will check in something which can be tested, and at the same time can now automate checks for breaking the build.
Automated testing is a time and cost saving tool. Why would anyone want to make software more expensive than necessary?
That is plain crazy. The dev's all use different versions of 3rd party libraries? No one tracks which features are to be deployed in each release? No branch capability in Version Control System?