mirror of
https://github.com/LCTT/TranslateProject.git
synced 2024-12-29 21:41:00 +08:00
159 lines
13 KiB
Markdown
159 lines
13 KiB
Markdown
|
Analyzing the DNA of DevOps
|
|||
|
|
======
|
|||
|
|
How have waterfall, agile, and other development frameworks shaped the evolution of DevOps? Here's what we discovered.
|
|||
|
|
|
|||
|
|
|
|||
|
|
If you were to analyze the DNA of DevOps, what would you find in its ancestry report?
|
|||
|
|
|
|||
|
|
This article is not a methodology bake-off, so if you are looking for advice or a debate on the best approach to software engineering, you can stop reading here. Rather, we are going to explore the genetic sequences that have brought DevOps to the forefront of today's digital transformations.
|
|||
|
|
|
|||
|
|
Much of DevOps has evolved through trial and error, as companies have struggled to be responsive to customers’ demands while improving quality and standing out in an increasingly competitive marketplace. Adding to the challenge is the transition from a product-driven to a service-driven global economy that connects people in new ways. The software development lifecycle is becoming an increasingly complex system of services and microservices, both interconnected and instrumented. As DevOps is pushed further and faster than ever, the speed of change is wiping out slower traditional methodologies like waterfall.
|
|||
|
|
|
|||
|
|
We are not slamming the waterfall approach—many organizations have valid reasons to continue using it. However, mature organizations should aim to move away from wasteful processes, and indeed, many startups have a competitive edge over companies that use more traditional approaches in their day-to-day operations.
|
|||
|
|
|
|||
|
|
Ironically, lean, [Kanban][1], continuous, and agile principles and processes trace back to the early 1940's, so DevOps cannot claim to be a completely new idea.
|
|||
|
|
|
|||
|
|
Let's start by stepping back a few years and looking at the waterfall, lean, and agile software development approaches. The figure below shows a “haplogroup” of the software development lifecycle. (Remember, we are not looking for the best approach but trying to understand which approach has positively influenced our combined 67 years of software engineering and the evolution to a DevOps mindset.)
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
> “A fool with a tool is still a fool.” -Mathew Mathai
|
|||
|
|
|
|||
|
|
### The traditional waterfall method
|
|||
|
|
|
|||
|
|
From our perspective, the oldest genetic material comes from the [waterfall][2] model, first introduced by Dr. Winston W. Royce in a paper published in the 1970's.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Like a waterfall, this approach emphasizes a logical and sequential progression through requirements, analysis, coding, testing, and operations in a single pass. You must complete each sequence, meet criteria, and obtain a signoff before you can begin the next one. The waterfall approach benefits projects that need stringent sequences and that have a detailed and predictable scope and milestone-based development. Contrary to popular belief, it also allows teams to experiment and make early design changes during the requirements, analysis, and design stages.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
### Lean thinking
|
|||
|
|
|
|||
|
|
Although lean thinking dates to the Venetian Arsenal in the 1450s, we start the clock when Toyota created the [Toyota Production System][3], developed by Japanese engineers between 1948 and 1972. Toyota published an official description of the system in 1992.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Lean thinking is based on [five principles][4]: value, value stream, flow, pull, and perfection. The core of this approach is to understand and support an effective value stream, eliminate waste, and deliver continuous value to the user. It is about delighting your users without interruption.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
### Kaizen
|
|||
|
|
|
|||
|
|
Kaizen is based on incremental improvements; the **Plan- >Do->Check->Act** lifecycle moved companies toward a continuous improvement mindset. Originally developed to improve the flow and processes of the assembly line, the Kaizen concept also adds value across the supply chain. The Toyota Production system was one of the early implementors of Kaizen and continuous improvement. Kaizen and DevOps work well together in environments where workflow goes from design to production. Kaizen focuses on two areas:
|
|||
|
|
|
|||
|
|
* Flow
|
|||
|
|
* Process
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
### Continuous delivery
|
|||
|
|
|
|||
|
|
Kaizen inspired the development of processes and tools to automate production. Companies were able to speed up production and improve the quality, design, build, test, and delivery phases by removing waste (including culture and mindset) and automating as much as possible using machines, software, and robotics. Much of the Kaizen philosophy also applies to lean business and software practices and continuous delivery deployment for DevOps principles and goals.
|
|||
|
|
|
|||
|
|
### Agile
|
|||
|
|
|
|||
|
|
The [Manifesto for Agile Software Development][5] appeared in 2001, authored by Alistair Cockburn, Bob Martin, Jeff Sutherland, Jim Highsmith, Ken Schwaber, Kent Beck, Ward Cunningham, and others.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
[Agile][6] is not about throwing caution to the wind, ditching design, or building software in the Wild West. It is about being able to create and respond to change. Agile development is [based on twelve principles][7] and a manifesto that values individuals and collaboration, working software, customer collaboration, and responding to change.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
### Disciplined agile
|
|||
|
|
|
|||
|
|
Since the Agile Manifesto has remained static for 20 years, many agile practitioners have looked for ways to add choice and subjectivity to the approach. Additionally, the Agile Manifesto focuses heavily on development, so a tweak toward solutions rather than code or software is especially needed in today's fast-paced development environment. Scott Ambler and Mark Lines co-authored [Disciplined Agile Delivery][8] and [The Disciplined Agile Framework][9], based on their experiences at Rational, IBM, and organizations in which teams needed more choice or were not mature enough to implement lean practices, or where context didn't fit the lifecycle.
|
|||
|
|
|
|||
|
|
The significance of DAD and DA is that it is a [process-decision framework][10] that enables simplified process decisions around incremental and iterative solution delivery. DAD builds on the many practices of agile software development, including scrum, agile modeling, lean software development, and others. The extensive use of agile modeling and refactoring, including encouraging automation through test-driven development (TDD), lean thinking such as Kanban, [XP][11], [scrum][12], and [RUP][13] through a choice of five agile lifecycles, and the introduction of the architect owner, gives agile practitioners added mindsets, processes, and tools to successfully implement DevOps.
|
|||
|
|
|
|||
|
|
### DevOps
|
|||
|
|
|
|||
|
|
As far as we can gather, DevOps emerged during a series of DevOpsDays in Belgium in 2009, going on to become the foundation for numerous digital transformations. Microsoft principal DevOps manager [Donovan Brown][14] defines DevOps as “the union of people, process, and products to enable continuous delivery of value to our end users.”
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Let's go back to our original question: What would you find in the ancestry report of DevOps if you analyzed its DNA?
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
We are looking at history dating back 80, 48, 26, and 17 years—an eternity in today’s fast-paced and often turbulent environment. By nature, we humans continuously experiment, learn, and adapt, inheriting strengths and resolving weaknesses from our genetic strands.
|
|||
|
|
|
|||
|
|
Under the microscope, we will find traces of waterfall, lean thinking, agile, scrum, Kanban, and other genetic material. For example, there are traces of waterfall for detailed and predictable scope, traces of lean for cutting waste, and traces of agile for promoting increments of shippable code. The genetic strands that define when and how to ship the code are where DevOps lights up in our DNA exploration.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
You use the telemetry you collect from watching your solution in production to drive experiments, confirm hypotheses, and prioritize your product backlog. In other words, DevOps inherits from a variety of proven and evolving frameworks and enables you to transform your culture, use products as enablers, and most importantly, delight your customers.
|
|||
|
|
|
|||
|
|
If you are comfortable with lean thinking and agile, you will enjoy the full benefits of DevOps. If you come from a waterfall environment, you will receive help from a DevOps mindset, but your lean and agile counterparts will outperform you.
|
|||
|
|
|
|||
|
|
### eDevOps
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
In 2016, Brent Reed coined the term eDevOps (no Google or Wikipedia references exist to date), defining it as “a way of working (WoW) that brings continuous improvement across the enterprise seamlessly, through people, processes and tools.”
|
|||
|
|
|
|||
|
|
Brent found that agile was failing in IT: Businesses that had adopted lean thinking were not achieving the value, focus, and velocity they expected from their trusted IT experts. Frustrated at seeing an "ivory tower" in which siloed IT services were disconnected from architecture, development, operations, and help desk support teams, he applied his practical knowledge of disciplined agile delivery and added some goals and practical applications to the DAD toolset, including:
|
|||
|
|
|
|||
|
|
* Focus and drive of culture through a continuous improvement (Kaizen) mindset, bringing people together even when they are across the cubicle
|
|||
|
|
* Velocity through automation (TDD + refactoring everything possible), removing waste and adopting a [TOGAF][15], JBGE (just barely good enough) approach to documentation
|
|||
|
|
* Value through modeling (architecture modeling) and shifting left to enable right through exposing anti-patterns while sharing through collaboration patterns in a more versatile and strategic modern digital repository
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Using his experience with AI at IBM, Brent designed a maturity model for eDevOps that incrementally automates dashboards for measuring and decision-making purposes so that continuous improvement through a continuous deployment (automating from development to production) is a real possibility for any organization. eDevOps in an effective transformation program based on disciplined DevOps that enables:
|
|||
|
|
|
|||
|
|
* Business to DevOps (BizDevOps),
|
|||
|
|
* Security to DevOps (SecDevOps)
|
|||
|
|
* Information to DevOps (DataDevOps)
|
|||
|
|
* Loosely coupled technical services while bringing together and delighting all stakeholders
|
|||
|
|
* Building potentially consumable solutions every two weeks or faster
|
|||
|
|
* Collecting, measuring, analyzing, displaying, and automating actionable insight through the DevOps processes from concept through live production use
|
|||
|
|
* Continuous improvement following a Kaizen and disciplined agile approach
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
### The next stage in the development of DevOps
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Will DevOps ultimately be considered hype—a collection of more tech thrown at corporations and added to the already extensive list of buzzwords? Time, of course, will tell how DevOps will progress. However, DevOps' DNA must continue to mature and be refined, and developers must understand that it is neither a silver bullet nor a remedy to cure all ailments and solve all problems.
|
|||
|
|
|
|||
|
|
```
|
|||
|
|
DevOps != Agile != Lean Thinking != Waterfall
|
|||
|
|
|
|||
|
|
DevOps != Tools !=Technology
|
|||
|
|
|
|||
|
|
DevOps Ì Agile Ì Lean Thinking Ì Waterfall
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
--------------------------------------------------------------------------------
|
|||
|
|
|
|||
|
|
via: https://opensource.com/article/18/11/analyzing-devops
|
|||
|
|
|
|||
|
|
作者：[Willy-Peter Schaub][a]
|
|||
|
|
选题：[lujun9972][b]
|
|||
|
|
译者：[译者ID](https://github.com/译者ID)
|
|||
|
|
校对：[校对者ID](https://github.com/校对者ID)
|
|||
|
|
|
|||
|
|
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
|||
|
|
|
|||
|
|
[a]: https://opensource.com/users/wpschaub
|
|||
|
|
[b]: https://github.com/lujun9972
|
|||
|
|
[1]: https://en.wikipedia.org/wiki/Kanban
|
|||
|
|
[2]: https://airbrake.io/blog/sdlc/waterfall-model
|
|||
|
|
[3]: https://en.wikipedia.org/wiki/Toyota_Production_System
|
|||
|
|
[4]: https://www.lean.org/WhatsLean/Principles.cfm
|
|||
|
|
[5]: http://agilemanifesto.org/
|
|||
|
|
[6]: https://www.agilealliance.org/agile101
|
|||
|
|
[7]: http://agilemanifesto.org/principles.html
|
|||
|
|
[8]: https://books.google.com/books?id=CwvBEKsCY2gC
|
|||
|
|
[9]: http://www.disciplinedagiledelivery.com/books/
|
|||
|
|
[10]: https://en.wikipedia.org/wiki/Disciplined_agile_delivery
|
|||
|
|
[11]: https://en.wikipedia.org/wiki/Extreme_programming
|
|||
|
|
[12]: https://www.scrum.org/resources/what-is-scrum
|
|||
|
|
[13]: https://en.wikipedia.org/wiki/Rational_Unified_Process
|
|||
|
|
[14]: http://donovanbrown.com/
|
|||
|
|
[15]: http://www.opengroup.org/togaf
|