Fog Creek Software
Discussion Board




Daily builds for web projects

Are they possible and useful, or are daily builds reserved for traditional applications?

B
Thursday, February 21, 2002

Build early, build often works for web projects as well as for traditional projects.  For web projects, there isn't a compilation step (depending on the platform) but it's always good to test things as you go.

Wayne Venables
Thursday, February 21, 2002

For "web applications" for sure. 

razib khan
Thursday, February 21, 2002

Yes.  Web applications benefit from daily builds.  Because of how web applications are spread across servers, these projects can benefit just as much or more from daily builds as traditional apps because keeping servers in sync is not a simple problem if you have builds which are run infrequently (and hence are frequently broken).

Rick
Friday, February 22, 2002

Absolutely.  Although in a web based project, I'd equate a daily build to releasing the current project to QA for a sanity check to make sure major functionality didn't break.

I worked on a project that used Zope. www.zope.org which was a great tool.  But it's greatest weakness for app development is that it stores everything in it's object database.  Developers edit code in a browser window, and their changes are committed immediately.  This was originally chosen over file system based solutions like ASP or PHP because it didn't require creating a seperate file for every page you wanted to show.

This system eliminates most forms of source control, since there is no check-out/check-in system as well as building the product, etc.  It's impossible to find out who's changes broke the product without spending some time doing some serious digging.  Releasing to testing required having everyone stop working while the development DB was copied to the test machines.

Made early development very quick, but really started to show its warts once the project got larger and more developers were needed to work on it.

Made me a big advocate those previously rejected file-based systems.  You can impose more discipline on the development process when you can do things like source control and builds.

Bob

Bob Crosley
Friday, February 22, 2002

Nah. Daily builds are for wimps. Builds should run continuously. :) Don't believe me? Check out http://www.martinfowler.com/articles/continuousIntegration.html

I work on a large-ish web-based application, and we too use CruiseControl. (http://cruisecontrol.sourceforge.net/) It's still a little rough around the edges, but it's very helpful.

Roman Zabicki
Friday, February 22, 2002

Ant is your friend.  If you are using something other than Java, it probably still works.  Make is also good.

But the setup of the build system takes time, just like any other part of a system.

If you are asking this, I have to ask, what are you using for revision control.  If you web app is comletely scripted (PERL, PHP, etc) you may not need a deliberate compile step.

This is where uniot tests come in.  You build would probably be best configured as:
1) Blow away test Database and local code source
2) Check out from revision control.
3}Reinitailze database with baseline data
4) Populate database with sample data
5) Run Test scripts.  These should be automated.

This should be done as often as possible,, at least twice a day.  Catch conflicts when they occur,

Adam
Friday, February 22, 2002

It's important to point out that daily builds, by themselves, are almost worthless.  At most they'll only catch compilation errors; they can't tell you whether the software functions correctly or not.  In order for daily builds to make any sense, you need to test what you build.

Alyosha`
Saturday, February 23, 2002

You might want to check out Anthill.

AntHill is an open source tool for automating and controlling the build process. It offers a means to track every build, ability to recover and reproduce any build, hands-off operation. It provides a platform for sharing knowledge about software assets:central location for project websites including documentation, javadocs, project downloads, etc., automatic email notification of build status to interested parties It works as a process automation tool: automates the build process (nightly builds), can run unit tests with every build, generates source code metrics with every build, etc. and does eXtreme Programming by implementing continuous integration and running unit tests with every build. It also supports dependencies between projects.

http://www.urbancode.com/projects/anthill/default.jsp

justin rodham
Monday, January 20, 2003

*  Recent Topics

*  Fog Creek Home