ALM Summit 3 - Setting up a Continuous Delivery Deployment Pipeline with TFS
•
6 likes•8,023 views
Slides for my session at ALM Summit 3, at Microsoft Redmond.
Recommended
Recommended
More Related Content
What's hot
What's hot (8)
Viewers also liked
Viewers also liked (9)
Similar to ALM Summit 3 - Setting up a Continuous Delivery Deployment Pipeline with TFS
Similar to ALM Summit 3 - Setting up a Continuous Delivery Deployment Pipeline with TFS (20)
More from Jose Luis Soria
More from Jose Luis Soria (20)
Recently uploaded
Recently uploaded (20)
ALM Summit 3 - Setting up a Continuous Delivery Deployment Pipeline with TFS
- 1. Setting up a Deployment Pipeline with TFS José-Luis Soria jlsoria@plainconcepts.com @jlsoriat
- 2. Speaker Bio Chapter I Once upon a time, there was a little kid whose name was José-Luis. Nobody knows the actual reason, but he began to be interested in computers in the mid ’80s when, after so much careful consideration by his parents, he received an 8bit computer as a present, along with some other stuff such as a bicycle and pajamas. That day he felt so happy with the bicycle, so frustrated with the pajamas, and somewhat confused about how to properly deal with the computer. Soon he started to write all kinds of small and useless programs, but surprisingly none of them have made their way to being mentioned in the history of computer programming. Several years later he went to university, where he studied Computer Science and signed up for the weirdest student associations. His strange inclination for Application Lifecycle Management began unexpectedly one sunny spring day when, while playing a soccer match, he was hit hard on the head by the ball and lost consciousness. When he woke up in bed at hospital after a couple of days, all the words that came out of his mouth were about arcane and obscure matters related to version control systems, automated builds and similar kinds of esoteric no-brainers. From that moment on, his parents, close relatives and friends lost the small amount of hope they still had in Jose’s ability to succeed in life and be a person of worth. This behavior has done nothing but get worse until the present day, when he travels around the world trying to
- 3. (shorter) Speaker Bio • ALM Team Leader at Plain Concepts • Professional Scrum Trainer for Scrum.org • From Madrid, Spain • Knows about Continuous Delivery with TFS ;-)
- 4. In This Session, You’ll Learn… What a pipeline is Potential benefits Why bother Success criteria Who can use it Warning signs How to implement it
- 6. What is a pipeline?
- 11. Deployment Pipeline AUTOMATED COMMIT MANUAL TESTING RELEASE ACCEPTANCE TEST 1.0.1.1 1.0.1.2 1.0.1.3 AUTOMATED NON-FUNCTIONAL 1.0.1.4 ACCEPTANCE TEST MANUAL TESTING TESTING
- 12. Another example
- 14. Stages AUTOMATED COMMIT MANUAL TESTING RELEASE ACCEPTANCE TEST 1.0.1.1 1.0.1.2 1.0.1.3 AUTOMATED NON-FUNCTIONAL 1.0.1.4 ACCEPTANCE TEST MANUAL TESTING TESTING
- 15. The Cowboy Coder Pipeline COMMIT RELEASE FIGHT FIRES 1.0.1.1 1.0.1.2 1.0.1.3 AUTOMATED 1.0.1.4 ACCEPTANCE TEST MANUAL TESTING
- 16. The Bureaucratic Pipeline FILL ASK BOSS RESERVE SNEAK INT ACCEPT. MANUAL BRIBE THE COMMIT OFFICIAL FOR DEPLOY TICKET THE SERVE TEST TESTING PERMISSION AT IT DEPT. ADMIN ROOM FORM 1.0.1.1 1.0.1.2 1.0.1.3 AUTOMATED NON- NON- NON- NON- NON- MANUAL 1.0.1.4 ACCEPTANCE TESTING FUNCTIONAL FUNCTIONAL FUNCTIONAL FUNCTIONAL FUNCTIONA TEST TESTING TESTING TESTING TESTING TESTING
- 17. Instances: Changes, Builds or Versions AUTOMATED COMMIT MANUAL TESTING RELEASE ACCEPTANCE TEST 1.0.1.1 1.0.1.2 1.0.1.3 AUTOMATED NON-FUNCTIONAL 1.0.1.4 ACCEPTANCE TEST MANUAL TESTING TESTING
- 18. The Waterfall-ish Pipeline AUTOMATED COMMIT MANUAL TESTING RELEASE ACCEPTANCE TEST Spring 2008 Fall 2009 Summer 2011
- 19. Propagating Changes AUTOMATED COMMIT MANUAL TESTING RELEASE ACCEPTANCE TEST 1.0.1.1 1.0.1.2 1.0.1.3 1.0.1.4
- 20. Why bother to build a pipeline?
- 21. No early feedback A pipeline allows you to get feedback about changes as soon as possible. Each instance of the pipeline provides feedback about that change, while work is started on other changes
- 22. No visibility in the process The pipeline mirrors your process. All the aspects of the way you deliver are reflected in the pipeline. The status is clearly known at any time.
- 23. Paralyze development while releasing Work on new features, or any kind of change, can be started on a new instance of the pipeline, while releasing is done for older changes in existing instances.
- 24. Long and unpredictable release cycles It is always clear what steps are taken to release, and how long they last on average.
- 25. Lack of traceability about the origin of problems For each issue, you can always investigate the change that originated the instance of the pipeline where the issue appears.
- 26. Stressful, problematic and long deployments Stress-free deployments Deployments are automated and done frequently, so they nno longer represent a problem. Practice makes perfect.
- 27. Who else can benefit from a pipeline?
- 29. People working in silos
- 30. Teams facing an intolerable amount of bugs
- 31. Anyone willing to improve!
- 32. How to implement a pipeline
- 33. Is TFS well suited to setting up a Deployment Pipeline?
- 35. Build, test, code analysis Default build template
- 36. Prepare artifacts for later stages Web Deploy Custom workflows Database projects Scripting in general .bat, PowerShell…
- 38. Run automated tests, smoke-test deployments Write automated tests: MSTest, CodedUI, NUnit, xUnit, etc. Have the builds run these tests
- 39. Automate deployments, always deploy the same way Use custom workflow activities or deployment scripts: Web Deploy, bat, PowerShell, etc. Use the same automations all the time, with environments as parameters
- 40. Self-service deployments Set up builds that trigger the automated deployment. Use the Build-Deploy-Test workflow in Lab Management, deactivate the Build and Test parts if needed.
- 41. Environment provision & management, prepare to back out changes Use Lab Management to provision and manage environments. Use environment snapshots to back out changes. For standard environments, automate backup and restore
- 42. Practices not covered or needing clarification
- 43. Build only once Rebuilding from source at each step can introduce unexpected changes that could lead to issues. Use the Lab build template for stages other that the Commit Stage. If you can’t use Lab, set up a simple build template only for deployment and testing.
- 44. Propagate changes through the pipeline instantly Modify build definitions so they trigger the next step in the pipeline automatically, when needed. You can use a custom workflow activity for this. For example, the QueueBuild activity from the Community Extensions http://bit.ly/14vEEg3.
- 45. If any part of the pipeline fails, stop the line For automated steps, only trigger them if the previous one has been successful.
- 46. View pipeline status Write a custom dashboard. An easy option is to use OData for TFS (http://bit.ly/UDbiID). AUTOMATED COMMIT MANUAL TESTING RELEASE ACCEPTANCE TEST 1.0.1.1 1.0.1.2 1.0.1.3 AUTOMATED NON-FUNCTIONAL 1.0.1.4 ACCEPTANCE TEST MANUAL TESTING TESTING
- 47. Further improvements • Version builds: Versioning workflow activity from Community TFS Build Extensions (http://bit.ly/14vEEg3) • Build in parallel: parallel workflow activity, Parallel Template (http://bit.ly/VvSD4k)
- 48. Further improvements: Version Builds • Versioning workflow activity from Community TFS Build Extensions (http://tfsbuildextensions.codeplex.com/)
- 49. Lab Management is going to save you a lot of work. Use it!
- 50. Demo!
- 52. Transparent and predictable delivery process AUTOMATED COMMIT MANUAL TESTING RELEASE ACCEPTANCE TEST 1.0.1.1 1.0.1.2 1.0.1.3 AUTOMATED NON-FUNCTIONAL 1.0.1.4 ACCEPTANCE TEST MANUAL TESTING TESTING The pipeline reflects at any moment the way software is delivered, and the status of that process.
- 53. Less defects in production No reds ever reach the Release column. No regressions. AUTOMATED COMMIT MANUAL TESTING RELEASE ACCEPTANCE TEST 1.0.1.1 1.0.1.2 1.0.1.3 AUTOMATED NON-FUNCTIONAL 1.0.1.4 ACCEPTANCE TEST MANUAL TESTING TESTING
- 54. Flexibility to cope with changes AUTOMATED COMMIT MANUAL TESTING RELEASE ACCEPTANCE TEST 1.0.1.1 1.0.1.2 1.0.1.3 AUTOMATED NON-FUNCTIONAL 1.0.1.4 ACCEPTANCE TEST MANUAL TESTING TESTING Changes can be addressed in one or more new instances of the pipeline. Everything is already set up and ready.
- 55. Useful and actionable feedback AUTOMATED COMMIT MANUAL TESTING RELEASE ACCEPTANCE TEST 1.0.1.1 1.0.1.2 1.0.1.3 AUTOMATED NON-FUNCTIONAL 1.0.1.4 ACCEPTANCE TEST MANUAL TESTING TESTING Feedback is obtained multiple times, for every change (instance) that gets into the pipeline. There is more information, it arrives earlier and it’s more focused.
- 56. Shorter time to deploy and release AUTOMATED COMMIT MANUAL TESTING RELEASE ACCEPTANCE TEST 1.0.1.1 1.0.1.2 1.0.1.3 AUTOMATED NON-FUNCTIONAL 1.0.1.4 ACCEPTANCE TEST MANUAL TESTING TESTING Deployment is done automatically across most of the stages. Release is done frequently, for each change, so it’s a predictable and optimized process.
- 57. Empowered teams
- 58. Success criteria
- 59. Shorter Cycle Time Kanban board and Cumulative Flow Diagram: http://bit.ly/10Zomxd Interpreting a CFD: http://slidesha.re/cQjhmu
- 60. Greater automated test coverage Using code coverage: http://bit.ly/WtZGW7 Coverage reports: http://bit.ly/XIFtLZ Build summary report: http://bit.ly/Wu0ryd
- 61. Larger MTBF Check also Reporting on Work Items: http://bit.ly/VDng44 http://bit.ly/X1BACX
- 62. Improved Velocity Using the velocity report: http://bit.ly/YvWLCi
- 63. Impact on the code churn and frequency of check-ins Code churn reports: http://bit.ly/XIFtLZ http://bit.ly/b9oFiS Build summary report: http://bit.ly/Wu0ryd
- 64. Impact on build cadence Build summary report: http://bit.ly/Wu0ryd
- 65. Warning signs
- 67. Rebuilding from source and using environment- specific binaries Using the lab template helps to avoid rebuilding. Use the same binaries through all the stages.
- 68. Builds (steps) that take a great amount of time
- 69. Broken builds or failed steps not being addressed quickly
- 72. Configuration and other items not being versioned Put everything under version control. Use config transforms http://bit.ly/WwetSU. For non-web projects use slowcheetah http://bit.ly/VqOLhz.
- 73. Issues with branching • Keep your branching model as simple as possible. • Use Branch by Abstraction while developing http://bit.ly/X7RMRp. • Use Feature Toggles for deploying http://bit.ly/VqPSO7.
- 74. Poorly managed dependencies NuGet can help! Use NuGet package restore http://bit.ly/Wf9CX2. If you want more control, consider setting up your own NuGet feed http://bit.ly/WwqVlu.
- 75. Lack of rollback procedures Use Lab Management snapshots if available. Automate backups and rollback procedures.
- 76. Continuous Delivery = ≠ Continuous Deployment
- 77. Big ball of mud A BIG BALL OF MUD is haphazardly structured, sprawling, sloppy, duct-tape and bailing wire, spaghetti code jungle. http://www.laputan.org/mud/mud.html You CAN Continuously Deploy spaghetti to a BIG BALL OF MUD. That’s not Continuous Delivery.
- 78. Continuous Deployment is only a part of the whole picture! Continuous Delivery Automate environment Smoke-test provision deployments Propagate changes through Continuous Self-service …and much more!!! the pipeline Deployment deployments View pipeline status Test Build only Automation once Stop the line Deploy the same way to every Have a rollback environment procedure
- 79. Summary • A Continuous Delivery pipeline can address many typical problems with the software development process. • Visual Studio + TFS, with some customization, are suitable for setting up a pipeline (better with Lab Management). • When properly implemented, it can bring many benefits. • You have to watch out for some common warning signs.
- 80. Plain Concepts
- 82. Thanks! Any questions? jlsoria@plainconcepts.com @jlsoriat http://geeks.ms/blogs/jlsoria Get these slides: http://slidesha.re/11fljAc