Learning from the Early Adopters of DevOps: A Guidebook to Success featuring Forrester Research
•Als PPTX, PDF herunterladen•
1 gefällt mir•580 views
Many organizations have already taken the leap into DevOps. Luckily, this daunting path is now well lit with best practices from customer experience, toolkits for success, and warning signs for ugly DevOps practices. Guest host Amy DeMartine, Senior analyst at Forrester Research, and Perforce invite you to a live broadcast on using DevOps to break your team's bad habits and increase your business value with speed, minimal errors, and pro knowledge on new ways to collaborate. In this broadcast, you'll learn to: - Use Agile and DevOps to improve collaboration and simplify delivery - Avoid bad DevOps habits - Build a toolkit for success and embrace uncertainty - Reference a use case from one of Perforce's largest customers when setting up your own release cycles
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (20)
Ähnlich wie Learning from the Early Adopters of DevOps: A Guidebook to Success featuring Forrester Research
Ähnlich wie Learning from the Early Adopters of DevOps: A Guidebook to Success featuring Forrester Research (20)
Mehr von Perforce
Mehr von Perforce (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Learning from the Early Adopters of DevOps: A Guidebook to Success featuring Forrester Research
- 1. Learning from the Early Adopters of DevOps A Guidebook to Success from Forrester Research
- 2. 2© Perforce Software Inc. All Rights Reserved. Amy DeMartine Sr. Analyst Serving Infrastructure & Operations Professionals Forrester Research John Williston Product Marketing Manager & Developer Evangelist Perforce Software
- 3. Learning From The Early Adopters Of DevOps Amy DeMartine, Principal Analyst
- 5. © 2015 Forrester Research, Inc. Reproduction Prohibited 5 Source: “Boost Application Delivery Speed And Quality With Agile DevOps Practices”, Forrester report Application Release Cycles Are Long…
- 6. © 2015 Forrester Research, Inc. Reproduction Prohibited 6 Source: “Six Trends That Will Shape DevOps Adoption In 2016 And Beyond”, Forrester report And The Business Isn’t Happy
- 7. © 2015 Forrester Research, Inc. Reproduction Prohibited 7 DevOps provides a set of practices and cultural changes — supported by complementary tools — that automates the software delivery pipeline, enabling organizations to win, serve, and retain consumers better and faster than ever before. Source: “Brief: The State Of DevOps Industry Adoption For 2016 — Where's The Heat?” Forrester report.
- 8. © 2015 Forrester Research, Inc. Reproduction Prohibited 8 Source: “DevOps Makes Modern Service Delivery Modern”, Forrester report Goal is continuous delivery…
- 9. © 2015 Forrester Research, Inc. Reproduction Prohibited 9 Source: “Boost Application Delivery Speed And Quality With Agile DevOps Practices”, Forrester report Typical Application Release Bottlenecks
- 10. © 2015 Forrester Research, Inc. Reproduction Prohibited 10 Source: “Boost Application Delivery Speed And Quality With Agile DevOps Practices”, Forrester report Key Delivery Practices And The Release Cycles They Enable (Part 1)
- 11. © 2015 Forrester Research, Inc. Reproduction Prohibited 11 Source: “Boost Application Delivery Speed And Quality With Agile DevOps Practices”, Forrester report Key Delivery Practices And The Release Cycles They Enable (Part 2)
- 12. © 2015 Forrester Research, Inc. Reproduction Prohibited 12 Source: “Boost Application Delivery Speed And Quality With Agile DevOps Practices”, Forrester report Key Delivery Practices And The Release Cycles They Enable (Part 3)
- 13. © 2015 Forrester Research, Inc. Reproduction Prohibited 13 51% of respondents claimed partial version control but only 37% claim full version control of all artifacts in the continuous delivery pipeline. Source:. Q1 2016 Global Modern Service Delivery Benchmark Online Survey, Base 142 I&O professionals., Forrester report
- 14. © 2015 Forrester Research, Inc. Reproduction Prohibited 14 Source:. “The Quest For Speed-Plus-Quality Drives Agile And DevOps Tool Selection” Forrester report Tools Help Glue The Continuous Delivery Pipeline Together
- 15. © 2015 Forrester Research, Inc. Reproduction Prohibited 15 Key Takeaways › To transform customer experience and accelerate the digital business we need to release quicker. › Releasing quicker relies heavily on automation but also strong processes and cultural shifts.
- 16. All This Has Happened Before…
- 17. 17© Perforce Software Inc. All Rights Reserved. A Trip Down Memory Lane
- 18. 18© Perforce Software Inc. All Rights Reserved. Developers • Little system access • Code in the closet • Every run unique • Versioning only by duplicate decks, disks, tapes, etc. In the Beginning Operators • Unlimited access • Storage was precious • Every run a chore • System software versioned by different tapes/disks
- 19. 19© Perforce Software Inc. All Rights Reserved. • Complexity forces unity, Dev + Ops • Tighter iteration -> better products • Automating the grunt work • Significant competitive advantages Today’s DevOps Movement
- 20. DevOps Is Not One Size Fits All
- 21. 21© Perforce Software Inc. All Rights Reserved. • DevOps grew from the web • Comparatively small projects • Minimal legacy burdens • Largely simple deployment The Ideal Case
- 22. 22© Perforce Software Inc. All Rights Reserved. • Legacy apps -> more work • Divide and conquer • CI first, then CT and CD • Evolutionary process Legacy Applications
- 23. 23© Perforce Software Inc. All Rights Reserved. • Bringing contributors together • Driving down build cycles • Automating testing and validation • Automating staging and deployment • Managing / automating infrastructure • Securing and maintaining history immutably in perpetuity Common Goals
- 25. 25© Perforce Software Inc. All Rights Reserved. • Old world: craftsmen and guilds • The industrial revolution: • Sequenced units of work • Staged them all in a pipeline • Integrated those units of work • Tested and shipped the final products/services • Doesn’t that sound familiar? The Manufacturing Parallel
- 26. 26© Perforce Software Inc. All Rights Reserved. • The new world has dev, ops, and more • In the DevOps movement: • Work delivered as units • Staged in a pipeline • Units integrated automatically • Testing, packaging, and deployment are automated • All of this has happened before… The Modern Equivalent
- 27. 27© Perforce Software Inc. All Rights Reserved. • Plethora of clients, plugins, and tools • Proven federated server architecture • Branches, streams, advanced DVCS • Code review and collaboration • Broad integrations and APIs • The one system you’ll never outgrow Helix is the Digital Assembly Line
- 28. 28© Perforce Software Inc. All Rights Reserved. DevOps Pipeline Overview Helix Versioning Engine Infrastructure Management (i.e. Chef, Puppet) Integration (CI) Test (CT) Delivery (CD)Contributors Customers
- 29. 29© Perforce Software Inc. All Rights Reserved. • Tearing down silos • Component based development • Minimize cycle times • Performance and scalability • Artifact management Continuous Integration Helix Versioning Engine IM Tool (i.e. Chef, Puppet) Manage Artifacts Build Tool Check in/ Check out RC
- 30. 30© Perforce Software Inc. All Rights Reserved. • Test document storage • Scripting automation • Environment storage • Automated provisioning • Acceptance testing • Validation and verification Continuous Testing Helix Versioning Engine IM Tool (i.e. Chef, Puppet) Test (CT) Release Test Scripts
- 31. 31© Perforce Software Inc. All Rights Reserved. • Final signing / stamping • Retain installers / packages • Infrastructure as code • Automated provisioning • Staging <-> production swap • Compliance reporting Continuous Delivery Helix Versioning Engine IM Tool (i.e. Chef, Puppet) Delivery (CD)Release Log Data MD5 Signatures, etc.
- 32. 32© Perforce Software Inc. All Rights Reserved. • Infrastructure as code • Bare metal to node(s) • Node config / manage • Full orchestration • Store light containers • Store full VMs Infrastructure Management
- 33. 33© Perforce Software Inc. All Rights Reserved. • Scania uses Perforce Helix • DevOps improved everything: • Tore down the silos • United all contributors • Accelerated the build process • Took testing to a new level • And that’s just the beginning It’s Not Just Us
- 34. Amy DeMartine @AmyDeMartine Forrester Research John Williston @p4jbw Perforce Software Questions?
- 35. Thank you for attending!
Hinweis der Redaktion
- The pendulum of history swings, particularly in computing history DevOps can be seen as the natural outcome of what should be a familiar pattern By tracing this pattern, we can draw a useful analogy that highlights useful truths
- The whole developer-operator distinction was born with the nature of the first computers. Dev and ops were necessarily opposed, due to the nature of the computer and their goals/roles. Being so scarce, expensive, and hard to maintain, the first generation of were universally shared resources, supported (and protected) by a dedicated IT "priesthood" of operators. Developers had their source on cards, tapes, shared storage, disks, etc. and requested runs, sometimes through an entirely separate language (e.g., IBM's JCL). The notion of an "install set" really wasn't a thing. Programs had to be compiled, executed, and the resulting output (or list of errors) dumped as a single unit of work. The first major inflection point (roughly 1975 – 1992) was the advent of the personal computer (PC), which changed everything, for the first time making it possible for individuals to own a computer and thus load and execute their own software, sometimes without relying on dedicated operations personnel at all. This generation of computing, was characterized by its reliance on developers producing a single directory structure and often installing the new version on any officer servers/machines themselves. The individual programmer, or small team, was responsible for producing the release, and often had to invoke the various steps manually. For example, it wasn't uncommon to execute a make utility to build object modules from C files and subsequently link them into an executable image. The subsequent "release process" was often little more than copying that entire folder tree to the appropriate local folder, network share, or appropriate media (floppy disks, tapes, etc.) for distribution.
- PC software grew exponentially more complicated as computing power became increasingly ubiquitous (roughly 1992 – 2007). Challenges included supporting various client/server deployment models, network topologies, multiple platforms, etc. Because of this, the burdens on developers grew correspondingly and complicated the release process to the point where installers became essential tools for software delivery to the masses. Increasingly what developers produced was handed off through a relatively primitive pipeline stitched together from custom processes, all of this typically managed by build/release engineer(s) distinctly separate from developers. The individual programmer, or small team, was often responsible only for producing working builds, which were then handed off to others. For example, it wasn't uncommon for developers to execute a make utility to build object modules from C/C++ source files and subsequently link them into an executable image. That image could then be included in a directory structure, along with other files and folders (often hand copied), to form an overall release target. Said "golden build" was then handed off to others who invoked subsequent tools to transform that resulting target into working installers for appropriate distribution media (CD, DVD, etc.). What characterizes the third wave of software development was rectifying the second wave error of separating developers and operations. The focus of the Agile movement on iterating with diminishing release cycles made the old ways impossible to sustain. The early pipeline and its processes had to be reimagined with both developers and operations specialists involved, alongside other stakeholders as well. For example, circa 2016 it isn't uncommon for the entire pipeline to be driven by a Continuous Integration tool like Jenkins. Such CI tools often to execute a make utility to build object modules from *.c files and subsequently link them into an executable image. That image could then be included in a directory structure, along with other files and folders (often hand copied), to form an overall release target. Subsequent tools were often invoked by hand to transform that resulting target into appropriate distribution media (CD, DVD, etc.).
- TODO: The logos I copied/pasted need some help. It would be nice if there were some way to make this consistent with the original diagram, like the previous slides, but I’m out of ideas on that point.
- For details see: http://devops.com/2016/06/28/scania-adopting-devops-auto-production/ TODO: Need the link to the Scania video from MERGE 2016