• Like
Build automation best practices
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Build automation best practices

  • 2,831 views
Published

 

Published in Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
2,831
On SlideShare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
29
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Build Automation Best PracticesDaniel 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