From XP and Continuous Integration to DevOps

2,119 views

Published on

Agile and Automation have been growing up together over the past decade. Neither practice nor toolset evolves in a vacuum. Rather, they inform each-other.

This presentation looks at this history, with an eye towards where the current trends are pushing us.

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,119
On SlideShare
0
From Embeds
0
Number of Embeds
9
Actions
Shares
0
Downloads
64
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • Speaker: Jeff
  • In 2001, Scrum is marketted as a way to get started with XP
  • Automation – less work, and more accuracy
  • Automation – less work, and more accuracy
  • Scrum – Project Management to Scrum MastersCI – Build management. Used to have build guys. Now we have build tooling guys.There are bumps!
  • Scrum – Project Management to Scrum MastersCI – Build management. Used to have build guys. Now we have build tooling guys.There are bumps!
  • Operations can’t release, prepare for a release at the pace developers.
  • Scrum – Project Management to Scrum MastersCI – Build management. Used to have build guys. Now we have build tooling guys.There are bumps!
  • From XP and Continuous Integration to DevOps

    1. 1. From CI to DevOps Agile and Automation evolution Eric Minick Technical Evangelist eric@urbancode.com1
    2. 2. Manifesto for Agile Software Development We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:Individuals and interactions over processes and toolsWorking software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more.2
    3. 3. A Historical Perspective3
    4. 4. 90’s: Daily Build and Smoke Test4
    5. 5. Tinderbox5
    6. 6. 1999: “Daily builds are for wimps”6
    7. 7. 2001: First open source “CI” tools7
    8. 8. 2003: We know CI works• 90% rise in LOC output/programmer when performing builds at least daily• 36% reduction in defect rate when integration/regression testing at each code check-in“Trade-offs between Productivity and Quality in Selecting Software Development Practices”, IEEE Software, Sept-Oct 20038
    9. 9. Agile &Automationin 2001-2004 AutomationAgile (XP) (Continuous Integration)• Small teams • Build focused• Developer-centric • Developer testing• High discipline • Open source• Co-located • Lava lamps9
    10. 10. 2005-2010: To the Enterprise!10
    11. 11. The Ken Schwaber Index 2001 2004 201011
    12. 12. Enterprise Agile… Governance?“…clients told me of their plans to use Scrum on a $5 million project with 400 developers in three countries… “Its not the engineering practices that will trip us up, continuous integration, test first, refactoring – these things are understood. Its governance that’s going to be the problem.”12 http://blogs.gartner.com/david_norton/2010/01/20/enterprise-agile-in-2010/
    13. 13. Agile &Automationin 2006-2011 AutomationAgile (Scrum) (Continuous Delivery)• Small& large teams • Self-service• Cross Functional • Builds, tests &• Standardized deployments• Distributed • Enterprise • Shared infrastructure13
    14. 14. Invention and Innovation14
    15. 15. The difference• Invention: proven to work in the laboratory• Innovation: it can be replicated reliably on a meaningful scale at practical costs.• For an idea to move from invention to innovation requires an ensemble of critical components. Peter M. Senge, The Fifth Discipline15
    16. 16. Scrum: Innovation for Agile• Predictable delivery, comfortable pace• Agile with fewer objectionable demands• Certifications and Training16
    17. 17. CI: Innovation for Automation• Automation• Instant feedback on quality• Easy setup with off the shelf tools• Self-service• Transparency/Visibility17
    18. 18. Innovations are disruptive18
    19. 19. CI Builds Build Management Builds Purpose: determine quality Purpose: produce artifacts of latest changes for 3rd parties Audience: development Audience: 3rd parties outside team development Source: Build is traceable Source: Build is traceable to to latest changes and source “latest” source Artifacts: Throw away Artifacts: Important builds, tests are builds, artifacts are important important and primary19
    20. 20. Agile has conquered App-Dev20
    21. 21. Today: Failure in the last mile21
    22. 22. Valuing “Working Software” means working in Production22
    23. 23. DevOps: Agile reaches Ops23 *image from Dev2Ops.org
    24. 24. DevOps is…• Agile & Lean applied to the whole software delivery chain, not just developers – BizDevQaSecReleaseOps• Driven by efficiency and consistency• Optimizing software delivery end-to-end24
    25. 25. DevOps is also disruptiveDev Ops• Very High Tempo • Slower Tempo• Can rebuild database / app • Incremental updates to from scratch Database and App – No need for Rollbacks – Rollbacks are huge• Audit is nice to have • Audit Critical – Security, traceability, separ – Security, traceability, separ ation of duties. ation of duties.• New Environments are • New environments are common rare25
    26. 26. DevOps: the Implementation, Convergence• IaaS on a private cloud• Environment provisioning as a service.• Application Deployment (CD) to provisioned environments.26
    27. 27. Agile &Automationin 2012+Agile Automation(Scrumban + DevOps) (Provision -> Monitor)• Small& large teams • Platform as a Service• Business to Ops • Provision, build, test,• Standardized deploy, monitor• Distributed • Enterprise• RM build to Prod • Shared infrastructure27
    28. 28. Where are the tools headed?• 2001-2006: CI tools• 2006-2010: CI becomes Continuous Delivery• Now: DevOps – CI is commodity. – Integrated CD tools focus on point solutions deployment and pipeline management. – Expanding integrations with private cloud28
    29. 29. Doing the impossible 50-times a day29
    30. 30. Manifesto for Agile Software Development We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:Individuals and interactions over processes and toolsWorking software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more.30
    31. 31. What do I do Tomorrow?31
    32. 32. Thank You Eric Minick Technical Evangelist eric@urbancode.com32

    ×