building software

Tools of the Trade – Build Environment

Posted on August 9, 2008. Filed under: building software, software development, team building |

  • Source Control
  • Bug Tracking Software
  • Dedicated Build Environment
  • Testing
  • Documentation
  • Modern Hardware
  • Can we build it?  Yes, we can!

    But can you build it again?  and again?  and, oh how about rebuilding that release we did 6 months ago for that weird client who wanted the application in Esperanto?

    Oh?  You swapped your machine over to Linux since then!

    Oh?  You have switched to mono!

    Oh? You now use MonoDevelop!

    I think that everyone knows that techies (developers especially) love installing new applications and widgets and open source projects and who knows what else on their machines. 

    I used to install trial versions of games onto my development machine.  That was great fun until the day that visual studio would no longer worked.  I guess that somebody got a bit overzealous with their uninstall program and started deleting libraries that they thought were not needed by other programs.  The end result is that I spent a couple days reformatting the machine and reinstalling everything. 

    works on my machine, starburst

    The developers favourite excuse when the testers come forward with a bug: “Well it works on my machine”

    For those reasons and more, you need to have a machine that is dedicated to building your software.  It needs to be a pristine and bare bones installation from the ground up.  Access to the machine needs to be controlled and the fact that no one messes with the build machine needs to be hammered home.

    You could even go so far as to use virtual machines for the build machine and keep different images (or at the least checkpoints) around for when you make changes to the build environment.  While Microsoft does its best to not blow things up with patches, it does happen (XP SP3 ring any bells?). 

    While it is helpful to have a dedicated build person or team of builders, that isn’t so important.  I feel that it is important that everyone on the development know how to build and install the software.  If the developers are so focused on little pieces of code and unfamiliar with the big picture then trouble will be brewing down the line.

    I like to designate one person as the build primary and let them deal with the details of building the code and distributing the build and maintaining the build notes.  Since most people don’t like this job (and to ensure that everyone is familiar with the process), it is a good idea to rotate this on a regular basis.  However, don’t assign the shiny new face as being in charge of builds; they don’t know the software, they don’t know the team, they don’t know the system environment; despite their brilliance and inspiration to do an excellent job they will mess up.

    Advertisements
    Read Full Post | Make a Comment ( None so far )

    Liked it here?
    Why not try sites on the blogroll...