Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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:

  1. Daily builds were meant for projects following Agile practices. It does not work for the waterfall model.
  2. 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.
  3. 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.
  4. 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"

share|improve this question
add comment

4 Answers 4

up vote 8 down vote accepted

Your friends are being lazy and IMO unprofessional - the world will soon pass them by.

Daily builds were meant for projects following Agile practices. It does not work for the waterfall model.

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 impractical for projects where the graphics part ...

Automated testing is a time and cost saving tool. Why would anyone want to make software more expensive than necessary?

not necessary to have configuration management

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?

share|improve this answer
3  
I did daily builds in the early 1990s. When it took hours to complete a full build it was important to set aside hardware and get at least one full build per day to avoid drifting into non-buildable state. When that build was successful it usually became the next build for QA Engineers to work on and run automated regression tests. None of this had anything to do with Agile vs. Waterfall back then. For most product teams some kind of repeated waterfall was it. Some of us were doing iterative adaptive style then, it just wasn't called Agile yet. –  joshp Aug 10 '12 at 6:27
4  
Heck, I was working on projects in the 1980s that did nightly builds! We did have both ones and zeroes back then. Now, get off my lawn, sonny-boy! :-) –  Stuart Marks Aug 10 '12 at 7:30
    
Updated - daily / nightly builds have been around forever then. One of the our main reasons for doing them regularly and at night was because our C++ took ages to compile, at least until precompiled headers came about. –  StuartLC Aug 10 '12 at 7:37
    
My friends and their seniors are un-initiated into the culture of nightly builds and CI. That's why they can't yet see the benefit of it or about how to go about implementing it. Nice to know it can be used for any kind of project. I guess I'll try using these tools to create a demo project at home to try and introduce the concept. –  Nav Aug 10 '12 at 9:39
add comment

To be fair to your discussion partners, if what they have works, then, well, it works. I'd still probably sell them CI in some form, but I can understand the resistance.

There is an overhead to getting CI set up in the first place, and an overhead for managing it. Not a huge over head, but I point blank refuse to be "The CI guy" ever because I know at some point it will become an unwanted chore.

However, once I've nominated someone else to get it configured, at the very least it is beneficial to know that the code checked in is compiling. That one benefit alone is significant.

The testing side of it is kind of irrelevant here. The CI build should run tests, but those tests shouldn't exist if they serve no useful purpose. There are always test cases that do make sense though. This is also a point of resistance for many developers.

Some people still see code test coverage as a golden statistic of project health. It isn't. I'd still rather have 1pc coverage with that 1pc being appropriate, quality tests, rather than 80pc coverage of "Tests I wrote because we needed to get to 80pc coverage".

And that's the final issue. Once you've got CI, someone is going to ask you for coverage statistics, then they will ask why your coverage isn't higher, then someone will send you a link to a great UI testing package that automates... In their mind they've gone from a process which demonstrably works, to a process which requires more effort to get to the same end result, the same working code they were delivering previously.

share|improve this answer
    
+1 for writing tests for only the important parts. The 80/20 rule applies very well in this field. –  Hoàng Long Aug 10 '12 at 7:59
add comment

Daily builds were meant for projects following Agile practices. It does not work for the waterfall model.

I would say: pure waterfall does not work for more than trivial projects with a lifetime so small that setting up a daily build would be oversized. But if your project lifetime is at least several months, and you mean "waterfall with recurring cycles", then of course daily builds can make a lot of sense. And even in a classical waterfall, where you have an analysis, a design and a development phase, in the development phase you have to do a lot of builds and code integration, so why not automate this and make sure the code changes integrate daily?

Continuous integration required automated testing

Nonsense, CI can integrate automated testing, but that's not a requirement. You can still test manually and use CI only for making sure you have a daily build ready for your testers.

One of them believes that it's not necessary to have configuration management.

If you have a project where the life cycle of your product ends after release 1.0, then this is true. In all other cases, you should have some kind of config management. But this is independently from CI. Furthermore, CI encourages you to keep your changes to your code base small and reintegrate daily - which exactly was your argument here against it.

Even if they created scripts for the entire build and burn-to-cd process, creating automated tests were a problem

See my comment, CI does not require automatic testing.

And to your other points:

you can't always know what tests you'd have to run

all of them, what else?

scripting a test case for it takes up too much time

You should script those test cases where applying them manually over and over again takes too much time, so having them automated will save you time.

automated testing tools may not always support the specific kind of tests you might want to make

Because there are some possible tests you have problems to automate, you don't automate anything? Does not sound very convincing to me. And who told you automated testing needs special tools? I would just start without any tools or only with some lighweight xUnit framework.

share|improve this answer
    
sorry, about configuration management, I meant to type "believes that it's not necessary to integrate configuration management with development tools". I've added an edit to my question. –  Nav Aug 10 '12 at 11:49
add comment

RE: Testing difficult-to-specify & difficult-to-test systems such as graphics systems.

In my experience, testing is not just (even?) about testing the output of the system that you are building. It is about verifying that the assumptions that you have made are correct, and continuing to verify those assumptions as the project evolves and situations change.

To this end, the placement of a moderate number of assertion statements at various points in the code has enormous benefit when combined with a continuous integration regime.

The system does not even need to be exercised with a comprehensive suite of unit tests (although these are a good thing if you have the time), Even a small set of vigorous system-level exercises will provide tremendous utility in uncovering bugs and building confidence.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.