Fog Creek Software
Discussion Board




benefits of daily build if not integrating daily?

what are the  benefits of doing a daily build if you are not integrating code daily?

actually, what is the value in general?

i was with a group that did a build every 1.5 weeks on a wednesday afternoon. we then tested on thursday and friday. if things really fell apart then we would have to work saturday.

Patrick
Thursday, August 12, 2004

> what are the  benefits of doing a daily
> build if you are not integrating code
> daily?

Assuming that the daily build is done to detect defects in the code integrated on that day, if you don't integrate any code, you'll get no defects. So, it has a morale-boosting value :)

> actually, what is the value in general?

The greatest advantage is that you reduce the scope of the problem.

If it built correctly yesterday and it doesn't today, then you have 1 day's work to look at; if it built correctly 2 weeks ago and it doesn't today, then you have 2 week's work to look at.

In 2 weeks you may have already have created dependencies on the broken code, and fixing it may require more effort.

Paulo Caetano
Thursday, August 12, 2004

Daily builds need to be used with automated tests -- they go hand in hand.  If the daily build and the automated test both succeed then you probably have not broken anything major.

BTW QA should only be given weekly builds, they would go nuts trying to stay current with a daily build.

O Canader
Thursday, August 12, 2004

At one place I started a daily build practice and the build would be broken every few days.  Eventually with the my harrasment of the offenders the build then only failed every couple of weeks.  We weren't even close to automated testing but quality improved but we only went from really really bad to really bad.

Bill Rushmore
Thursday, August 12, 2004

The next step then is to make it mandatory that a developer check out before checking in, doing his own build and passing whatever minimum smoke tests you have.

Then and only then can they check in the code.

This is because the main cause of broken daily builds with multiple developers is that someone changed something with some kind of dependancy.

So, the mantra is.

Checkout source required and no more
Make changes
Test, validate
Checkout and merge
Smoke test
If it passes, check in

This doesn't eliminate them since some bright spark could break something before you check back in, but it minimises it and gives you the least amount to back out to fix it.

Simon Lucy
Thursday, August 12, 2004

We require developers to immediately test all check-ins on a test build machine dedicated for that purpose. Just checking on their machines isn't enough, since it won't catch changes they forgot to check, in or new files they forgot to add (both of which used to cause about 90% of our build failures).

Bob
Thursday, August 12, 2004

we used to do the following:
- check out the latest build
- make changes
- unit test (supposedely)
- check in changes
- every 1.5 weeks build
- regression/acceptence test for 1-2 days

i view unit testing as just testing your function that you change. I view integration testing on testing your changes with the rest of a module.

so should you check-in or unit-test first?

Patrick
Thursday, August 12, 2004

You should check out and merge before checking in.

Simon Lucy
Thursday, August 12, 2004

http://www.15seconds.com/issue/040810.htm

zigzag
Thursday, August 12, 2004

As far as handoff to QA goes, our general rule was "only check in stuff that works", so QA was free to grab any daily build they wanted to. Rather than a "dev pushes to QA" model, we had a "QA pulls".

QA didn't check every daily build, but whenever they were ready they just grabbed the latest successful build and went to town. It worked out really well; QA was never waiting on dev, and the devs tended to get fairly quick feedback from QA.

Chris Tavares
Thursday, August 12, 2004

Chris:

I'm sure that our QA would love to have a pull model.  Our issue is that the client, server and database all need to be in synch.  We're still pretty early on in this project so schema changes are happening frequently, the client/server communication protocol change way too often.

O Canader
Thursday, August 12, 2004

If you do a daily build you can also do a daily/overnight test run. We used to do this using JUnit and it was great to get into work to see 100% success rate with the test runs.  :-)

OTOH, when tests failed the usual incrimination and finger pointing would take place. Still, it's a great confidence booster when the build/test cycle works :-&

TheGeezer
Thursday, August 12, 2004

> Our issue is that the client, server and database all need to be in synch.

Should these three be in the same version control system: so that your QA can "get all" at any time, and be able to assume that whatever was in to be pulled is in synch?

Christopher Wells
Thursday, August 12, 2004

>> You should check out and merge before checking in.

Actually, it's:

get-latest and merge, before checking in

Gunnar Skogsholm
Friday, August 13, 2004

*  Recent Topics

*  Fog Creek Home