本文首发于 JenkinsCI 公众号，源自 Jenkins 的创始人 Kohsuke Kawaguchi （简称 KK）在 QCon 北京上的主题演讲：「Why，What，and How of Continuous Delivery」。没听到现场演讲，仔细研读PPT之后，整理笔记如下。

编外的话

KK是一位摄影爱好者，所以PPT里会有大量精美的图片，这 PPT 看着多舒心呀！笔者有幸在北京和KK有过一次亲密接触，并和KK畅聊 Jenkins 及 DevOps。

真的不是我矮啊，只是KK太高了😊

Kohsuke Kawaguchi（KK）于2004年开发了 Jenkins 项目的前身（Hudson），一开始就是为了解决他自己的关于自动化的需求。他自己也没想到13年后，Jenkins 成了软件交付过程中的核心工具，驱动着千万企业的持续交付与 DevOps 过程。

这次主题演讲KK系统的分析了持续交付与 DevOps 的体系、现状、路线图和模式，和 Patrick 在 DevOpsDays · 北京站的演讲一样，大神为我们点亮了命星！

整理的重点内容：

1. 持续交付框架分析 2. 敏捷/持续交付/DevOps成熟度现状、级别划定、改进四象限与路线图等 3. DevOps转型策略 4. 工程实践简介
5. 持续交付的黄金思维圈

1、流程线已经改变过一次世界

福特在引入流水线生产之后，Model-T 的组装时间缩短了8倍。1.3万名员工生产了30万量汽车，超过了300家竞争对手的总和，这就是效率的神话。

不过后来丰田超越了福特，在不确定性越来越突出的现在，单纯的效率已经不能满足企业的竞争，所以精益、敏捷、DevOps 才会出现，继续探索软件开发新模式、拓展效率和质量的新边疆。

2、软件正在吞噬世界

这个是共识，这是全人类的挑战和机遇，对我们从事工程效率和过程改进的人来说，不断改进软件交付的方式和效率，没有止境。

3、头号需求：业务连续性（不停机）

各大权威机构对 IT、DevOps、Continuous Delivery 的预测和评估。

我认为业务连续性也只是其中一项需求而已，整体上来讲，我们要解决的两个问题是：Build the things right and Build the right things。

从 KK 的 PPT 里获取的信息是，他认为，持续交付和自动化是我们需要的答案之一。

4、持续交付框架分析

KK 的持续交付相关内容梳理的很清晰。这张图也可以说是 DevOps 的管理与工程实践框架。KK 也强调了 DevOps 是一组文化方法和技术实践。

维度：

1. 阶段：产品定义、计划、编码、编译、构建、单元测试、分析、集成、集成测试、打包、Place、压力测试、验收测试、发布、部署、监控
   其中的构建和编译、单元测试并列，不清楚这里的构建表示什么？我理解的构建时编译、打包、或者在加上单元测试、代码分析的整体。自动化构建的目标就是要输出（高质量）可以部署和测试的软件包。
   另外，关于Place也没有找到对应的解释，有点像部署或者分发

2. 环境

3. 开发环境

4. 预发布环境（类生产环境）

5. 生产环境
   关键中缺少独立的测试环境，从图上的分布看，应该是包含在Development中的

6. 方法

7. 敏捷
   「对特性进行识别、排序、调整的增量开发方法」。不太理解，敏捷的具体方法框架有很多，包括Scrum，XP，Kanban（准确的说属于精益方法）。还有 SAFe，Less 等规模化框架。

8. 持续集成
   持续集成是持续交付的基础，持续交付是 DevOps 的核心工程实践。非常重要。

9. 持续交付

10. 持续部署另外，红色框的逻辑没有理解明白，有高手请指点。
    

5、生存还是毁灭，你可以选择

每年的 State of DevOps Report 都会公布四个关键指标的数据：部署频率、周期时间、部署失败率、故障修复时间。高效能IT组织和低效能IT组织的差异非常大。KK的这两张图也非常形象的说明了这个问题。

6、现状和方向

6.1 敏捷团队占比

现状是上游敏捷（管理过程，比如Scrum）的团队占比33%，下游敏捷（持续交付）的团队占比13%。

这也符合国内的情况，很多团队刚开始做敏捷的时候都是从管理过程开始敏捷，大多从 Scrum 入手，但是效果一般都不尽如人意。

我认为持续集成和自动化测试是敏捷的两条腿，想要敏捷跑起来，此二者必须同时建设才能让敏捷体现其快速响应变化的价值。

6.2 非敏捷团队占比

根据 KK 的数据，目前有87%的团队，依然没有实现下游的敏捷，即持续交付和持续部署的实施较少或者不成熟。这会导致价值的交付依然长达数月之久。

6.3 成熟度级别

KK 将敏捷（CD、DevOps）的级别划分为团队级，跨团队级，企业级。这个和 DevOps 之父 Patrick 的 DevOps 5个精进级别颇为相似。

企业级的敏捷和 DevOps 还有很长的路要走。企业级的改进需要组织、文化都要共同变化。

编者：之前在参加敏捷培训时，老师提到诺西在敏捷方面做的很早也很深入，摩托做 CMMI 和 6 Sigma 也做的很好，但是这些企业现在都不在了。组织、战略、文化的敏捷至关重要。下边的人玩儿的很嗨，只是用正确的方法在做错误的事情而已。颇有感触！

6.3 改进四象限

KK 基于团队级、跨团队级、企业级以及上下游阶段，将改进方向划分为四个象限。

1. 团队级的敏捷 2. 团队级的CD 3. 企业级的敏捷 4. 企业级的DevOps（我相信2017和2018年，国内企业一定会迈进企业级的DevOps转型和落地）

6.4 改进路径与模式

KK 基于四象限将改进划分为2条路径和2种模式

路径一：

从团队敏捷到企业级（组织级）敏捷，再到企业级 DevOps

路径二：

团队级敏捷—>团队级持续交付—>企业级敏捷—>企业级 DevOps

我所了解的企业，偏向于类似第二种的路径，一开始都在团队级别进行敏捷和持续交付的尝试，逐渐成熟推广复用，规模化。

· 自下而上的改进

这种模式应该是比较常见

· 自上而下的改进

DevOps转型策略

KK给出了自己的建议：

1. 识别试点项目 2. 组建跨职能团队 3. 采用统一的技术 4. 基于可度量的KPI和里程碑制定计划 5. Go 6. 度量，文档化，改进 7. 规模化实践

关于第4点，我个人一直不喜欢考核，尤其是KPI。我希望的是一种能将工程师导向良性行为的评估方式。但是KK提到的可度量，是一种可取的方式，可度量意味着可执行，有目标。

但是度量一定要慎之又慎。一句话：度量改变行为。

7、工程实践

关于持续交付，KK重点强调了：A straightforward and repeatable deployment process is important for continuous delivery.

7.1 架构与实现技术

1. 特性开关

2. 灰度发布

3. 微服务
   以上三个技术对发布和部署都有很大的提升，特性开关可以调整应用的运用时状态，灰度发布逐步的切换流量，微服务可以做到单个服务的独立发布和部署。

4. 基础设施技术

5. 蓝绿部署

6. 金丝雀发布

7. 凤凰环境

8. 不可变基础设施

7.2 基于Jenkins的CD/DevOps生态系统

Jenkins是驱动整个持续交付和DevOps的核心组件。

8、DevOps 黄金思维圈

以上就是我在研读 KK 的 PPT 过程中的思考和记录，没到现场，所以感觉很零散。恰好最近刚接触一个概念：黄金思维圈，如下图所示：

黄金思维圈帮助我们认知世界，当然也可以帮助我们认知持续交付，尝试分析了一下：

Why：
持续且快速、可靠的自动交付软件给用户：

1. 实现价值的持续交付，赢得市场竞争 2. 提升研发（增值活动）的时间，极大化增值活动产出

How：
建设自动化、可重复、可靠的持续交付流水线（IT服务供应链）
主要包括代码管理、持续集成、自动化测试、自动化部署、基础设施自动化管理等方面的工程能力。

What：

1. 每次代码提交都需要经过流水线验证 2. 每次部署的版本都经过多环境验证 3. 部署频率可以得到提升 4. 周期时间（从代码提交到部署上线）的时间可以到分钟级 5. 部署失败率低 6. 部署失败的修复时间短，影响小

近期好文：

《DevOps绞杀者之路》

《DevOps创始导师首次访华内容全曝光，传播最正统的理念和方法》

《腾讯QQ日请求12亿的运营平台到底有多diao(三声)？》

《8种常被忽视的SQL错误用法》

如果你关注 DevOps 

DevOpsDays · 上海站

你不该错过

点击「阅读原文」，享受 DevOpsDays · 上海站特价优惠