Tech Off Thread

5 posts

Forum Read Only

This forum has been made read only by the site admins. No new threads or comments can be added.

Is a build server really necessary?

Back to Forum: Tech Off
  • User profile image
    ehuna

    Before .Net when our applications (COM, MFC, etc...) needed to be compiled and deployed I always insisted on making sure on the following process:

    1) The developers checked in all source code (VSS, Perforce, whatever source control system you prefer).

    2) The person responsible for the build would  then get the latest source from source control and attempt to compile it.

    3) The resulting binaries would then be deployed to QA, and the same build image would then be deployed to Production (whatever that means: a web farm, a master CD, etc...).

    The above process has a few advantages:

    1) All code is properly checked in (there are no "forgotten" classes, files, etc... lost when the developer's hard drive crashes).  In many cases, if a file is forgotten, the project won't compile

    2) Any third party dependencies are immediately indentified.  For example, if the developer installed a third party OCX on his/her environment the project won't compile on the build server.

    3) All compiled binaries created on the build server are "clean" (for example for linked libraries, the correct DLL would be used, and not some strange DLL installed on the developer's system).

    Now, with .Net, whatever code is being compiled is really ending up as IL.  So for companies with smaller 2-3 development teams, where some developers are also responsible for deploying the apps, does it still make sense to go through a build server.

    I understand there are still benefits (1 and 2 above), but if we find other ways to make sure code and dependencies are checked in or documented, would it be ok to bypass the build server all together?

    What do folks do at Microsoft?  Anyone has any strong feelings either way?

  • User profile image
    DoomBringer

    Yeah, its a good idea to have a dedicated build machine.  Keep it clean.  Oftentimes, a workstation gets a lot of gunk that might do funny things.  Also, keep a document that details how to establish a build environment, AND TEST IT.  If the coder leaves or the company has a disaster, recovery will be easier if you have a guaranteed method to get back up and running.

  • User profile image
    out180

    Virtual Machines are great for this.  Nothing says you can't have a build machine living in a VMware or VPC virtual machine. 

    If I archive a project I also compress and archive all the development and build images and create new ones for the next project.  That way, 12 months later when I need to jump back in I just decompress and fire them back up excatly where I left off.  No worry of how your development or build system might have changed in the past 12 months.  You are always guaranteed to have the exact same setup.

  • User profile image
    JohnLawr

    By cooincidence, a Channel 9 video just got posted this morning at http://channel9.msdn.com/ShowPost.aspx?PostID=128230#128230 which we set up so that I could talk a bit about how we implement these kinds of SCM practices at Microsoft - and also how we support such build machines in the upcoming Team Foundation Server. I can't quite remember but I think we may even have a demo in there somewhere.

    Bottom line is that I believe having a dedicated build environment is critical to successful, reliable, software delivery. If you simply pick up drops directly from a devlopers regular environment you can't guarantee that you'll be able to have daily builds, you can't have confidence that you can reproduce the same build on demand, and there is the risk that the environment is fragile - developers frequently have to rebuild their environments and you don't want to reach a point where you're without builds for a period because the build machine isn't available.

    Team Build (in Team Foundation Server) is designed to solve these problems. You can define builds to be run on a build machine - they're built in a clean environment, always with the latest source code, and can automatically kick off automated tests, copy the resultant binaries to a drop share etc. You can run this on a separate box (probably recommended) but you could also safely host it on a developers machine, because the environment is completely separate from the developer's workspace.



  • User profile image
    ehuna

    This is really good stuff.  Thanks, guys. Smiley

Conversation locked

This conversation has been locked by the site admins. No new comments can be made.