Continuous Delivery 2.0: Dual‑Loop Model, DevOps Practices, and Organizational Insights

The article originates from a Beijing offline meetup on April 20, 2019 titled “Continuous Delivery 2.0”.

“Continuous Delivery 2.0” is the author’s ten‑plus‑year summary of product R&D management experience, describing a “continuous delivery system” that includes software infrastructure, organizational management, and software architecture, with the dual‑loop model as the book’s framework.

1. Continuous Delivery 1.0 and DevOps

Continuous Delivery 1.0 (a group of processes, methods and systems) refers to the traditional long release cycles of enterprise applications that follow a waterfall approach: requirements → development → deployment to production.

In this model a version ends once the code is released, which is typical for many traditional software companies.

Internet companies extend the loop to include “product monitoring”, forming a closed‑loop iterative development process.

Continuous Delivery 1.0 focuses on moving code to production quickly so users can use it, which aligns with the current focus of DevOps.

DevOps (a group of processes, methods and systems) was coined by consultant Patrick DeBois to promote collaboration among development, operations, and QA.

Case 1: Flickr – In 2009 a Flickr engineer and an operations engineer presented at the Velocity conference how they achieved ten deployments per day, proving rapid, high‑quality releases were possible.

Flickr’s public data showed 54 deployments per week in 2010, involving 23 engineers and 636 code changes.

Case 2: Etsy – In 2010 Etsy began its continuous delivery journey and by 2012 could deploy more than 50 times per day, roughly one deployment every 15 minutes.

All developers commit to a single code repository; each commit triggers automated build, test (≈15 minutes), and, if successful, deployment to production.

Case 3: LinkedIn – In 2016 LinkedIn’s 3 000 engineers performed 905 code changes per week across iOS, Android, Web and API, illustrating high‑frequency releases.

The author explains why many Chinese companies still follow a “three‑week release plan” that often collapses under deadline pressure, leading to rushed code, manual testing, defects, and delayed releases.

2. Continuous Delivery 2.0 Dual‑Loop Model

Continuous Delivery 2.0 starts from business value exploration rather than software requirements, emphasizing a complete problem‑to‑solution loop.

The dual‑loop model consists of a “Scientific Exploration” loop (defining the problem, generating many solutions) and a “Rapid Validation” loop (quickly testing selected solutions).

LinkedIn’s “Navigator” project (2015) set a 3×3×3 goal: three weekly beta releases, three daily alpha releases, and a three‑hour lead time from code commit to an internal testable version.

The author stresses that culture (data‑validation, rapid‑feedback, engineering‑quality) and tools (self‑service, automation, “machines waiting”) are essential for DevOps success.

3. DevOps Culture and Tools

Key cultural elements: data‑validation, rapid feedback, engineering quality. Tool considerations include employee self‑service, eliminating manual hand‑offs, and automating workflows.

Self‑service means a team member can complete his own task without needing assistance from others (e.g., releasing a version without waiting for a tester or ops approval).

4. Key Points of Continuous Delivery 2.0

Lean Thinking & System Thinking – Eliminate waste (unused features, waiting, hand‑offs, inventory, defects). Distinguish “necessary waste” (testing) from “unnecessary waste”.

Four Basic Working Principles :

Do Less – Focus on the most important work; break large problems into small, valuable tasks.

Continuously Decompose Tasks – Split big requirements into many small code changes to obtain fast feedback.

Insist on Fast Feedback – Increase release frequency while maintaining quality; high‑frequency releases enable rapid trial‑and‑error.

Continuous Improvement – Inspired by Toyota, improve any process at any time; eliminate waste gradually.

5. Continuous Delivery Puzzle (Seven‑Piece Puzzle)

The author uses the traditional “seven‑piece puzzle” as a metaphor: enterprises must assemble infrastructure, organization, and architecture modules according to their own goals, rather than copying others.

Continuous Delivery 2.0 should become a sustainable organizational capability, delivering real business value without relying on unsustainable overtime.