devops practices: continuous delivery
DESCRIPTION
The DevOps movement, like its Agile predecessor, is focused on improving the communication and collaboration between the development and operations teams responsible for different aspects of an app throughout its lifecycle. While successful DevOps initiatives start and end with organizational and cultural change, there are also common practices that are enablers and/or tools used in support of DevOps. In this session you will learn about the DevOps practice of Continuous Delivery—releasing and deploying application changes as they are available, and not waiting for big, cumbersome roll-ups of new code. This session will focus on the practice of Continuous Delivery, while demonstrating a few tools that can make implementing Continuous Delivery easier, including tools for automated provisioning and release orchestration. If you are interested in implementing a DevOps initiative in your organization, then this session is a must-see.TRANSCRIPT
DevOps Practices:Continuous DeliveryDoug [email protected]
Releasing software should be a repeatable, reliable process.
Continuous Delivery Principle
Continuous Delivery Process
http://tinyurl.com/DevOps-CD
Delivery Team
Version Control
Build & Unit Test
Automated Acceptance
Test
User Acceptance
TestsRelease
Check-in Trigger
Trigger
Feedback
Feedback
ApprovalApproval
Continuous Integration
http://tinyurl.com/DevOps-CD
Delivery Team
Version Control
Build & Unit Test
Automated Acceptance
Test
User Acceptance
TestsRelease
Check-in Trigger
Trigger
Feedback
Feedback
ApprovalApproval
Every check-in is a potential release candidate.
Continuous Delivery Principle
Continuous Inspection
http://tinyurl.com/DevOps-CD
Delivery Team
Version Control
Build & Unit Test
Automated Acceptance
Test
User Acceptance
TestsRelease
Check-in Trigger
Trigger
Feedback
Feedback
ApprovalApproval
Mistakes v. Defects
• Mistakes are errors in action and are unavoidable.
• A defect is a mistake that goes uncorrected to a customer.
• Defects are entirely avoidable.
Quality Inspection
• Judgment Inspection - Inspect quality in
• Informative Inspection - Inspect at each stage
• Source Inspection - Build quality in
Poka-Yoke
ポカヨケ“mistake-proofing”
http://tinyurl.com/DevOps-PY
Poka-Yoke
ポカヨケ“mistake-proofing”
http://tinyurl.com/DevOps-PY
Poka-Yoke
ポカヨケ“mistake-proofing”
http://tinyurl.com/DevOps-PY
Poka-Yoke
ポカヨケ“mistake-proofing”
http://tinyurl.com/DevOps-PY
Build quality in.Continuous Delivery Principle
Continuous Deployment
http://tinyurl.com/DevOps-CD
Delivery Team
Version Control
Build & Unit Test
Automated Acceptance
Test
User Acceptance
TestsRelease
Check-in Trigger
Trigger
Feedback
Feedback
ApprovalApproval
KnightmareTHE $460M DEPLOYMENT
Knightmarehttp://tinyurl.com/DevOps-Knightmare
• Knight Capital Group• 3.3 billion trades daily.• $21.5 billion traded daily.• $365M cash & equivalents.
Knightmarehttp://tinyurl.com/DevOps-Knightmare
• NYSE launches Retail Liquidity Program on August 1, 2012.
• “SMARS” updates to support RLP.• New parent-child order system in SMARS
update.• Repurposed 8-yer old “Power Peg” flag.
Knightmarehttp://tinyurl.com/DevOps-Knightmare
• July 27, 2012 to July 31, 2012.• Manually deployed SMARS update.• Limited number of servers daily.
Knightmarehttp://tinyurl.com/DevOps-Knightmare
“During the deployment of the new code, however, one of Knight’s technicians did not copy the new code to one of the eight SMARS computer servers.” SEC Filing | Release No. 70694 | October 16, 2013
Knightmarehttp://tinyurl.com/DevOps-Knightmare
• 9:30 AM – Market opens.• 212 small retail “parent-orders”.• 7 servers processing “child-orders” correctly.• 8th server using the old Power Peg code failed
to recognized parent-orders were fulfilled.• 8th server sent cumulative child-orders in rapid
succession.
Knightmarehttp://tinyurl.com/DevOps-Knightmare
• No automated fail-safe.• No procedures for how to react.• Knight uninstalled the correct SMARS code
from the seven servers where it had been deployed correctly.
Knightmarehttp://tinyurl.com/DevOps-Knightmare
• 9:30 AM to 10:15 AM• 4 million executions in 154 stocks.• 357 million shares.
• $460 million in losses in 45-minutes.
Automate as much as is reasonable.
Continuous Delivery Principle
Configuration as CodeExecution CodeEnvironment
Application
Demo: PowerShellDesired State Configuration (DSC)http://tinyurl.com/DevOps-DSC
Keep everything in version control.
Continuous Delivery Principle
Release Management
• Orchestration of release pipeline.• Automate deployment to all environments.• Fail deployment at the earliest stage.
‘Done’ means released.
Continuous Delivery Principle
Continuous Delivery Process
http://tinyurl.com/DevOps-CD
Delivery Team
Version Control
Build & Unit Test
Automated Acceptance
Test
User Acceptance
TestsRelease
Check-in Trigger
Trigger
Feedback
Feedback
ApprovalApproval
Continuous Integration
http://tinyurl.com/DevOps-CD
Delivery Team
Version Control
Build & Unit Test
Automated Acceptance
Test
User Acceptance
TestsRelease
Check-in Trigger
Trigger
Feedback
Feedback
ApprovalApproval
Continuous Inspection
http://tinyurl.com/DevOps-CD
Delivery Team
Version Control
Build & Unit Test
Automated Acceptance
Test
User Acceptance
TestsRelease
Check-in Trigger
Trigger
Feedback
Feedback
ApprovalApproval
Continuous Deployment
http://tinyurl.com/DevOps-CD
Delivery Team
Version Control
Build & Unit Test
Automated Acceptance
Test
User Acceptance
TestsRelease
Check-in Trigger
Trigger
Feedback
Feedback
ApprovalApproval
Continuous Delivery Principles
• Releasing software should be a repeatable, reliable process.
• Every check-in is a potential release candidate.
• Build Quality In.• Automate as much as is reasonable.• Keep everything in version control.• ‘Done’ means released.
Resourcehttp://tinyurl.com/DevOps-Book
© 2013 Microsoft Corporation. All rights reserved. Microsoft, Windows and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries.The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.