Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Build automation best practices


Published on

Published in: Technology
  • Be the first to comment

Build automation best practices

  1. 1. Build Automation Best PracticesDaniel Sniderman – Lead Consultant
  2. 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• Professional Trombonist – currently with B.S. Brass Band and Prohibition Orchestra of Chicago• Father of two
  3. 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. 4. Why Automate your Build?• Do any of these sound familiar?• IT WORKED ON MY MACHINE!
  5. 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. 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. 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. 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. 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. 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. 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. 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. 13. Resources TFS• MSDN: Configuring and Managing your build system:• “Inside the Microsoft Build Engine: Using MSBuild and Team Foundation Server 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 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. 14. Resources Continuous Delivery•• “Continuous Delivery : Reliable Software Releases through Build, Test and Deployment Automation”