- Build automation helps ensure consistent builds, prevents errors, and speeds up the release process. It helps development teams integrate and deliver changes continuously. - Common tools for build automation include MSBuild, Team Foundation Server, CruiseControl.NET, and Hudson. These tools help with continuous integration (CI), running tests, code analysis, versioning, and deploying builds. - Best practices include CI on every code check-in, running unit tests as part of the build to prevent bugs, and continuously delivering integrated builds to environments for testing. This supports rapid and reliable software delivery.

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