Build Automation Best Practices Daniel Sniderman – Lead Consultant

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

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.

Why Automate your Build?

• Do any of these sound familiar?

• IT WORKED ON MY MACHINE!

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

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

“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”

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

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

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

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

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)

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

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