July 27, 2007 CI Factory, Continuous Integration

Making the Build Fast

There are many ways to make a build fast.  Some solutions are technical and some are conceptual.  Some are made in the build script and some are made in the product.  I thought I should share some of the ways I have been successful at making builds fast.

  1. When does the timer start?  Trigger the build when the developer commits, don’t poll.
  2. Only some of the people are happy all the time.  Make a developer facing build and cut out everything that you can.
  3. 9 woman can make a baby in a month.  Use asyncexec to maximize system utilization.

I have not been lucky enough to work on a project that maintained it’s own Subversion repo.  If I had I would of implemented something like TFS’s alerts, this should be a cinch with Captain Hook.  In TFS you can subscribe to the checkin(translates to commit) event and be called back on a web service.  I have utilized this functionality in CI Factory.Stop-watch   When a developer checks-in, TFS immediately calls CI Factory, triggering a build.  A developer checks-in and cctray immediately shows the activity as building.  This is a dramatic change from poll based triggers.  Remember the clock starts ticking when the developer commits not when the build actually starts.  This understanding can be a great lever.  If the poll cycle takes 2 minutes this is a huge opportunity.  The opportunity to remove 2 minutes from the build just by triggering the build on the commit.

Don’t try and do it all in one build.  Don’t try and satisfy Developers, Testers, and Managers in one build; their needs are not all compatible.  For example Developers don’t want to wait for the installer to be created.  Take a look at all the needs you’er trying to fulfill, workout which are compatible, and make a build for each compatible group.  A developer build can be incremental, a release build should be from a clean get.

If your build machine has multiple processors, which it should, you should be taking advantage of them.  Figure out what parts of your build can be executed concurrently.  The key word here is can, it was not make everything use asyncexec.  You will need to play around on the hardware that your build server runs on.  Play with the different combinations until you find the fastest.  Remember that many of the build operations are IO intensive.

A quick technical note.  The release build should not be building anything that has not already been built by the developer build.  The release build will be changing the version information files (assemblyinfo and productinfo).  There is no need for these changes to cause the dev build (if it is hosted on a different server) and the developers personal builds to rebuild projects.  Make sure there is a touch command in place to prevent this waste of time.

P.S. Michael we don’t record trending info on personal builds but it is a priority to make the personal build script soo fast that you prefer to use it over the IDE.  Soo fast that you always run it before your commit. 

4,537 Total Views

Leave a comment

*

here