Date post: | 29-Aug-2014 |
Category: |
Technology |
Upload: | code-mastery |
View: | 3,310 times |
Download: | 4 times |
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 [email protected]
• 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