Why Continuous Delivery Matters: Insights from Jenkins Founder KK’s QCon Talk

Introduction

This article was first published on the JenkinsCI public account and is based on Jenkins founder Kohsuke Kawaguchi’s (KK) QCon Beijing keynote titled “Why, What, and How of Continuous Delivery.” The notes below summarize the key points from the presentation.

Side Note

KK is an avid photographer, so his slides contain many beautiful images. The author met KK in Beijing and discussed Jenkins and DevOps with him.

1. Continuous delivery framework analysis
2. Agile/Continuous Delivery/DevOps maturity status, level definition, improvement quadrants and roadmap
3. DevOps transformation strategy
4. Brief engineering practice overview
5. The golden thinking circle of continuous delivery

1. The Production Line Changed the World Once

Ford’s assembly line reduced Model‑T assembly time by eightfold, allowing 13,200 workers to produce 300,000 cars—more than the combined output of 300 competitors. Later, Toyota surpassed Ford, and in today’s uncertain environment, pure efficiency is insufficient; lean, agile, and DevOps emerged to explore new software development models.

2. Software Is Consuming the World

This consensus represents a global challenge and opportunity; engineers focused on improving software delivery must continuously refine their processes.

3. Top Requirement: Business Continuity (No Downtime)

Various authorities predict the importance of IT, DevOps, and Continuous Delivery. The author believes the two core problems are “Build the things right” and “Build the right things.”

From KK’s PPT, continuous delivery and automation are part of the answer.

4. Continuous Delivery Framework Analysis

KK’s diagram clearly outlines a DevOps management and engineering practice framework, emphasizing that DevOps is a set of cultural methods and technical practices.

Dimensions:

Stage: product definition, planning, coding, compilation, build, unit test, analysis, integration, integration test, packaging, place, stress test, acceptance test, release, deployment, monitoring. (Note: “place” is unclear, possibly deployment or distribution.)

Environment

Development environment

Pre‑production (staging) environment

Production environment (note: a dedicated test environment appears missing)

Method

Agile – various frameworks such as Scrum, XP, Kanban, SAFe, LeSS, etc.

Continuous Integration – the foundation of continuous delivery.

Continuous Delivery

Continuous Deployment – the logical flow in the diagram is not fully understood.

5. Survival or Extinction – You Choose

Each year the State of DevOps Report publishes four key metrics: deployment frequency, lead time, change failure rate, and mean time to restore. High‑performance IT organizations differ dramatically from low‑performance ones, as illustrated by KK’s charts.

6. Current State and Direction

6.1 Agile Team Proportion

Upstream agile (process management, e.g., Scrum) teams account for 33% and downstream agile (continuous delivery) teams for 13%.

In China many teams start with upstream agile (often Scrum) but see limited results.

Continuous integration and automated testing are the two legs of agility; both must be built together.

6.2 Non‑Agile Team Proportion

According to KK, 87% of teams have not achieved downstream agility (continuous delivery/deployment), leading to months‑long value delivery cycles.

6.3 Maturity Levels

KK categorizes agile/DevOps maturity into team level, cross‑team level, and enterprise level, similar to Patrick’s five DevOps maturity stages.

6.4 Improvement Quadrants

Based on team, cross‑team, enterprise levels and upstream/downstream stages, KK defines four improvement quadrants.

1. Team‑level agile
2. Team‑level CD
3. Enterprise‑level agile
4. Enterprise‑level DevOps (expected to mature in 2017‑2018 in China)

6.5 Improvement Paths and Models

Path 1

From team agile to enterprise (organizational) agile, then to enterprise‑level DevOps.

Path 2

Team‑level agile → team‑level continuous delivery → enterprise‑level agile → enterprise‑level DevOps.

Bottom‑Up Improvement

A common pattern where teams start with agile and continuous delivery and scale up.

Top‑Down Improvement

Organizational‑driven change.

DevOps Transformation Strategy

1. Identify pilot projects
2. Form cross‑functional teams
3. Adopt a unified technology stack
4. Define measurable KPIs and milestones
5. Go
6. Measure, document, improve
7. Scale

While the author dislikes KPI‑driven assessments, measurable metrics can guide behavior change.

One sentence: Measurement changes behavior.

7. Engineering Practices

KK emphasizes that a straightforward, repeatable deployment process is essential for continuous delivery.

7.1 Architecture and Implementation Technologies

Feature toggles

Canary releases

Microservices – enable independent deployment of services.

Infrastructure technologies

Blue‑green deployment

Canary release (repeated for emphasis)

Phoenix environment

Immutable infrastructure

7.2 Jenkins‑Based CD/DevOps Ecosystem

Jenkins is the core component driving continuous delivery and DevOps.

8. DevOps Golden Thinking Circle

KK introduces a “golden thinking circle” to help understand continuous delivery.

Why: Deliver fast, reliable software continuously to win market competition and maximize value‑adding activities.

1. Enable continuous value delivery to win market competition
2. Increase the time spent on value‑adding activities, maximizing output

How: Build an automated, repeatable, reliable delivery pipeline covering code management, CI, automated testing, automated deployment, and infrastructure automation.

What:

1. Every code commit must pass the pipeline
2. Every deployment version is validated across multiple environments
3. Deployment frequency increases
4. Lead time from commit to production reaches minutes
5. Deployment failure rate is low
6. Failure recovery time is short and impact minimal