Continuous Integration is a wonderful concept. The basic idea is to get integration-level feedback as quickly as possible. It’s done wonders for cutting down on “it builds on my machine but not on anyone elses” phenomenon.
A piece of software, the free version of CruiseControl.NET in this case, runs on a PC and checks the version control repository periodically (usually every 15mins or so). Once it detects changes it grabs them and runs the build. So when you forget to check in that COM library that a library your library depends on needs you find out within 15mins or so instead of the next morning. Nightly builds are nice but continuous builds are nicer.
The rules of thumb that I’ve seen are for Progress bars are:
- If an action takes up to 3 seconds to complete show an hourglass/busy cursor.
- If an action takes 10 seconds or more then it needs to have a Progress Bar.
Progress Bars are pretty much the first thing to go when deadlines are tight so the holidays present a wonderful time to go back into those UIs on top of long running processes and add a progress bar.
When you've got a mix of managed and native code (a mixed blessing?) Visual Studio’s otherwise stellar dependency checking may show signs of wear. This is probably due to the cobbled together mixture of post-build scripts and external bat (or NAnt) scripts that represent your “evolutionary” build. The holidays are a wonderful time to make the build process less “evolutionary” and more “cultured” so-to-speak.