1. Build Automation Best Practices
Daniel Sniderman – Lead Consultant

2. About the Speaker
• BA History – Minor Computer Science University of Illinois at Urbana-Champaign
1984
• Professional Software Developer since 1983
• Specialist in Microsoft Technologies since 1994
• Consulting at Magenic since 2004
• MCSD.NET, MCTS:Team Foundation Server 2010
• Email Daniels@Magenic.com
• Professional Trombonist – currently with B.S. Brass Band and Prohibition
Orchestra of Chicago
• Father of two

3. Why Automate your Build?
• Do any of these sound familiar?
– The instructions to build the application is a four page Word Document (if it
even exists!).
– When the Lead Developer is on vacation, we can’t release the application.
– We’re never sure what version of the code is in our Dev, QA or Production
Environments.
– We sometimes have errors because someone “fat fingers” a configuration
change when going to a different environment
– It takes several hours to build and release our application
– One of the reasons we don’t have more releases (even to Dev/QA
environments) is that it’s very time consuming to deploy a release.

4. Why Automate your Build?
• Do any of these sound familiar?
• IT WORKED ON MY
MACHINE!

5. Best Practices – Continuous Integration
• Build Application on every check-in
• Lesser benefit for very small teams (1-3 developers)
• Ensure no one “Breaks the Build”
• With fast running unit-tests – can help prevent introduction of bugs
– Generally will preclude hitting a database
• “Gated Builds” can prevent check-in if build breaks or test fail

6. Next Level of Maturity: Nightly Integration Testing
• Nightly Build with a Test Suite that doesn’t have to be concerned with
how long tests take to run
• Build Should produce artifacts that can be used to automatically deploy
the application
– ASP.NET/Silverlight Applications and Web Services: MSDeploy script
– WPF/Windows Applications and Windows Services: MSI
– Frameworks and API’s: NuGet
– Windows 8 - Sideloading

7. “Build Nirvana” – Continuous Delivery
• Automatically Deploy the build to an environment where it can be tested by
QA/Stakeholders.
– Web Applications/Services deploy to Web Server
– Trickier for Windows Applications
• Setup VM
• Deploy to a machine on the network users can RDP to
• Make MSI available in a known location
• Term from Agile Manifesto (although principal can be applied to any
development methodology)
– “Our highest priority is to satisfy the customer through continuous delivery of
valuable software”

8. Common Build Automation Tools
• MSBuild
– Introduced with VS2008: every xxproj file (csproj/vbproj) etc is a MSBuild script –
used to determine order of compilation, automation etc
• nAnt
– Port of Java “ant” – commonly used before VS2008 and in some non-MSFT
products.
• Team Foundation Server
• Team City
• Cruise Control.NET (Open Source)
• Hudson
• Rake/pSake
• Many others

9. TFS Build – out of the box
• CI, Gated Builds, Scheduled Builds (nightly etc)
• Execute Tests – “Break the Build if they Fail”
– Third-party Test Frameworks supported
• Static Code Analysis
– Can break build if desirable if a rule is broken
• Label Code to a build for traceability
– And to recreated old releases at will
• Automatically Show Changes / Work Items since last build
– Automate Release Notes
• Track all of this history in a Data Warehouse

10. Common Build Automations
• Increment Version Number
– .Net Standard: Major.Minor.Build.Revision such as “14.0.6024.1000” for
Windows Word
• Include that Version Number in the “Build Name” for History and Labeling
• Update AssemblyInfo to include the version #, (Copyright Date etc) to stamp all
DLL’s/EXE’s
• Configuration Management is a must:
– Config or any other files that need to be changed per environment
• Copy build artifacts to FTP server if network boundary prevent automated
deployment

11. Database Deployment
• Redgate, Visual Studio can do this
• Often very tricky, may require manual interview (particularly to QA and
Production Environments)
• DBA’s generally work with a different set of tools

12. Getting Started
• Document your build process
• Look at incrementally replacing the steps in the document with
automation
• Document your deployment process
• Look at automation tools – even an “Xcopy deployment” can be
automated (Powershell, Robocopy etc)

13. Resources TFS
• MSDN: Configuring and Managing your build system:
http://msdn.microsoft.com/en-us/library/ms252495
• “Inside the Microsoft Build Engine: Using MSBuild and Team Foundation Server
http://www.amazon.com/Inside-Microsoft-Build-Engine-
Foundation/dp/0735645248/ref=sr_1_1?ie=UTF8&qid=1347417109&sr=8-
1&keywords=team+foundation+build (current to TFS2010)
• Professional Team Foundation Server 2012
http://www.amazon.com/Professional-Team-Foundation-Server-
2012/dp/1118314093/ref=sr_1_1?ie=UTF8&qid=1347417173&sr=8-
1&keywords=team+foundation+server+2012
– TFS 2010 version available now
– TFS 2012 version available Jan 2013

14. Resources Continuous Delivery
• http://www.continuousdelivery.com/
• “Continuous Delivery : Reliable Software Releases through Build, Test and
Deployment Automation”
http://www.amazon.com/dp/0321601912?tag=contindelive-20