Taming DevOps: The ‘Strangling’ Model to Turn Chaos into Continuous Delivery

1. Origin

I previously posted an article titled “The DevOps Tree Grown from Practice” on a high‑efficiency operations public account at the end of 2016, which received a lot of feedback. Readers felt they lacked a clear path and needed senior support to drive DevOps adoption, prompting me to propose the “DevOps Strangler” concept.

2. Outline

Today's talk covers three points:

1) Why DevOps seems difficult for many. 2) What the “Strangler” actually is and how to apply it. 3) My reflections on advancing DevOps.

3. Why Is It Hard?

Many treat DevOps like a child holding a huge apple—overwhelming because DevOps encompasses a vast concept, extensive knowledge, and many roles.

Wikipedia’s definition leaves most still unsure of what DevOps actually is. In essence, DevOps integrates operations into the entire software delivery process, surpassing traditional agile practices.

In waterfall, development, testing, and operations are siloed, leading to long delivery cycles and missed market opportunities. Agile improves development and testing collaboration but still isolates operations. DevOps unifies all three, enabling multiple deployments per iteration and continuous value delivery.

Beyond the many roles, DevOps’s knowledge base is complex, covering lean management, TPS, agile, continuous delivery, and IT service management.

Two key points to emphasize:

Testing is no longer a separate phase; it becomes an embedded capability across all stages (acceptance criteria, TDD, automated pipeline tests).

Disciplined Agile (DA) emphasizes strict team rituals—daily stand‑ups answering three questions, immediate fixing of broken CI—to enforce discipline.

DevOps is a synthesis of many practices, acting as a “mover” rather than a creator of concepts.

DevOps applies the Toyota Production System to software and internet domains. It embodies lean thinking and lean startup engineering. It is an end‑to‑end agile implementation. It offers a lightweight version of ITIL/ITSM.

Given DevOps’s breadth, how can we start? The answer lies in the “Strangler” approach.

4. The Strangler Model

The metaphor comes from tropical strangler figs that grow on host trees, eventually overtaking them. Similarly, DevOps should be introduced by “strangling” existing ineffective practices through focused, incremental improvements, eventually forming a robust DevOps “tree”.

The practice points (air roots) represent the DevOps capability model I previously defined at Yonyou and later refined during DevOps Master training.

The model includes dimensions such as:

Organizational culture – a healthy culture (e.g., Westrum’s generative type) is the foundation; continuous integration can foster quality awareness.

Visualization – measuring and visualizing delivery efficiency and quality (e.g., Kanban, technical debt metrics).

Agile development, continuous delivery, and technical operations – with continuous delivery as the core engineering practice.

If resources are limited, start with continuous delivery, which can be practiced by developers, testers, and operations alike.

Build‑Test‑Promotion Case Study

LeTV’s smart hardware (TVs, phones, cars) uses an Android‑based UI system. Previously, a daily build took over an hour, consumed heavy resources, and feedback cycles were long, with no continuous automated testing for core features.

We adopted a DevOps‑driven pipeline: every two hours we compile, package, and run automated tests, providing continuous quality verification.

A “quality gate” across development, integration, and QA ensures strict quality control, crucial for UI OS releases where recall costs are high.

LeTV’s ecosystem values and cross‑team collaboration (R&D, SCM, QA) underpin this practice.

5. Reflections

From my experience driving DevOps at Yonyou, I distilled five key activities:

Build consensus – define DevOps scope, goals, and assess organizational readiness.

Establish a community – bring together architects, ops experts, and agile practitioners to share practices.

Continuous sharing – disseminate engineering practices and tool platforms for reuse (e.g., ELK logging).

Define a framework – publish a DevOps guide covering philosophy, process, practice, and engineering.

Create a roadmap – map out incremental practice steps and visualise detailed methods.

DevOps does not have to start with top‑down design; incremental, ground‑level improvements can gradually “strangle” legacy practices and eventually grow a robust DevOps tree.