http://tinyurl.com/DevOps-CD
http://tinyurl.com/DevOps-CD
http://tinyurl.com/DevOps-CD
errors
mistake

unavoidable
uncorrected

• Defects are entirely avoidable.
Inspect quality in

Inspect at each stage
Build quality in
http://tinyurl.com/DevOps-PY
http://tinyurl.com/DevOps-PY
http://tinyurl.com/DevOps-PY
http://tinyurl.com/DevOps-PY
http://tinyurl.com/DevOps-CD
billion
billion
• $365M cash & equivalents.
• Repurposed 8-yer old “Power Peg” flag.
• Manually
one
of Knight’s technicians did not copy the new code to
one
• 7 servers

correctly
using the old Power Peg code

• 8th server sent cumulative child-orders in rapid

succession.
• No
• No

uninstalled the correct SMARS code
• 4 million
• 357 million

• $460 million in losses
Execution
Code

Application
Environment
pipeline
• Automate deployment
• Fail
earliest
http://tinyurl.com/DevOps-CD
http://tinyurl.com/DevOps-CD
http://tinyurl.com/DevOps-CD
http://tinyurl.com/DevOps-CD
http://tinyurl.com/DevOps-Book
DevOps Practices: Continuous Delivery
DevOps Practices: Continuous Delivery
DevOps Practices: Continuous Delivery
DevOps Practices: Continuous Delivery
DevOps Practices: Continuous Delivery
DevOps Practices: Continuous Delivery
DevOps Practices: Continuous Delivery
DevOps Practices: Continuous Delivery
DevOps Practices: Continuous Delivery
DevOps Practices: Continuous Delivery
DevOps Practices: Continuous Delivery
DevOps Practices: Continuous Delivery
Upcoming SlideShare
Loading in …5
×

DevOps Practices: Continuous Delivery

980 views
825 views

Published on

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.

Published in: Technology, Design
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
980
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
41
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • 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.
  • Poka-yoke (ポカヨケ?) [poka yoke] is a Japanese term that means "mistake-proofing". A poka-yoke is any mechanism in a lean manufacturing process that helps an equipment operator avoid (yokeru) mistakes (poka). Its purpose is to eliminate product defects by preventing, correcting, or drawing attention to human errors as they occur.[1] The concept was formalised, and the term adopted, by Shigeo Shingo as part of the Toyota Production System.[2][3] It was originally described as baka-yoke, but as this means "fool-proofing" (or "idiot-proofing") the name was changed to the milder poka-yoke.More broadly, the term can refer to any behavior-shaping constraint designed into a process to prevent incorrect operation by the user.[citation needed] Similarly, a constraint that is part of the product (or service) design is considered Design for Manufacturability or Design for X. A modern Poka-Yoke application is when a driver must press on the brake pedal (a process step, therefore a poka-yoke)) prior to starting an automobile. The interlock serves to prevent unintended movement of the car. An additional poka-yoke would be the switch in the car's gear shift that requires the car to be in Park or Neutral before the car can be started. These serve as behavior-shaping constraints as the sequence of "car in park (or neutral)" and/or "Foot on brake" must be performed before the car is allowed to start. Over time, the driver's behavior is conformed with the requirements by repetition and habit.
  • Poka-yoke (ポカヨケ?) [poka yoke] is a Japanese term that means "mistake-proofing". A poka-yoke is any mechanism in a lean manufacturing process that helps an equipment operator avoid (yokeru) mistakes (poka). Its purpose is to eliminate product defects by preventing, correcting, or drawing attention to human errors as they occur.[1] The concept was formalised, and the term adopted, by Shigeo Shingo as part of the Toyota Production System.[2][3] It was originally described as baka-yoke, but as this means "fool-proofing" (or "idiot-proofing") the name was changed to the milder poka-yoke.More broadly, the term can refer to any behavior-shaping constraint designed into a process to prevent incorrect operation by the user.[citation needed] Similarly, a constraint that is part of the product (or service) design is considered Design for Manufacturability or Design for X. A modern Poka-Yoke application is when a driver must press on the brake pedal (a process step, therefore a poka-yoke)) prior to starting an automobile. The interlock serves to prevent unintended movement of the car. An additional poka-yoke would be the switch in the car's gear shift that requires the car to be in Park or Neutral before the car can be started. These serve as behavior-shaping constraints as the sequence of "car in park (or neutral)" and/or "Foot on brake" must be performed before the car is allowed to start. Over time, the driver's behavior is conformed with the requirements by repetition and habit.
  • Poka-yoke (ポカヨケ?) [poka yoke] is a Japanese term that means "mistake-proofing". A poka-yoke is any mechanism in a lean manufacturing process that helps an equipment operator avoid (yokeru) mistakes (poka). Its purpose is to eliminate product defects by preventing, correcting, or drawing attention to human errors as they occur.[1] The concept was formalised, and the term adopted, by Shigeo Shingo as part of the Toyota Production System.[2][3] It was originally described as baka-yoke, but as this means "fool-proofing" (or "idiot-proofing") the name was changed to the milder poka-yoke.More broadly, the term can refer to any behavior-shaping constraint designed into a process to prevent incorrect operation by the user.[citation needed] Similarly, a constraint that is part of the product (or service) design is considered Design for Manufacturability or Design for X. A modern Poka-Yoke application is when a driver must press on the brake pedal (a process step, therefore a poka-yoke)) prior to starting an automobile. The interlock serves to prevent unintended movement of the car. An additional poka-yoke would be the switch in the car's gear shift that requires the car to be in Park or Neutral before the car can be started. These serve as behavior-shaping constraints as the sequence of "car in park (or neutral)" and/or "Foot on brake" must be performed before the car is allowed to start. Over time, the driver's behavior is conformed with the requirements by repetition and habit.
  • Poka-yoke (ポカヨケ?) [poka yoke] is a Japanese term that means "mistake-proofing". A poka-yoke is any mechanism in a lean manufacturing process that helps an equipment operator avoid (yokeru) mistakes (poka). Its purpose is to eliminate product defects by preventing, correcting, or drawing attention to human errors as they occur.[1] The concept was formalised, and the term adopted, by Shigeo Shingo as part of the Toyota Production System.[2][3] It was originally described as baka-yoke, but as this means "fool-proofing" (or "idiot-proofing") the name was changed to the milder poka-yoke.More broadly, the term can refer to any behavior-shaping constraint designed into a process to prevent incorrect operation by the user.[citation needed] Similarly, a constraint that is part of the product (or service) design is considered Design for Manufacturability or Design for X. A modern Poka-Yoke application is when a driver must press on the brake pedal (a process step, therefore a poka-yoke)) prior to starting an automobile. The interlock serves to prevent unintended movement of the car. An additional poka-yoke would be the switch in the car's gear shift that requires the car to be in Park or Neutral before the car can be started. These serve as behavior-shaping constraints as the sequence of "car in park (or neutral)" and/or "Foot on brake" must be performed before the car is allowed to start. Over time, the driver's behavior is conformed with the requirements by repetition and habit.
  • DevOps Practices: Continuous Delivery

    1. 1. http://tinyurl.com/DevOps-CD
    2. 2. http://tinyurl.com/DevOps-CD
    3. 3. http://tinyurl.com/DevOps-CD
    4. 4. errors mistake unavoidable uncorrected • Defects are entirely avoidable.
    5. 5. Inspect quality in Inspect at each stage Build quality in
    6. 6. http://tinyurl.com/DevOps-PY
    7. 7. http://tinyurl.com/DevOps-PY
    8. 8. http://tinyurl.com/DevOps-PY
    9. 9. http://tinyurl.com/DevOps-PY
    10. 10. http://tinyurl.com/DevOps-CD
    11. 11. billion billion • $365M cash & equivalents.
    12. 12. • Repurposed 8-yer old “Power Peg” flag.
    13. 13. • Manually
    14. 14. one of Knight’s technicians did not copy the new code to one
    15. 15. • 7 servers correctly using the old Power Peg code • 8th server sent cumulative child-orders in rapid succession.
    16. 16. • No • No uninstalled the correct SMARS code
    17. 17. • 4 million • 357 million • $460 million in losses
    18. 18. Execution Code Application Environment
    19. 19. pipeline • Automate deployment • Fail earliest
    20. 20. http://tinyurl.com/DevOps-CD
    21. 21. http://tinyurl.com/DevOps-CD
    22. 22. http://tinyurl.com/DevOps-CD
    23. 23. http://tinyurl.com/DevOps-CD
    24. 24. http://tinyurl.com/DevOps-Book

    ×