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

重点内容：

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 是一组文化方法和技术实践。

维度：

• 阶段：产品定义、计划、编码、编译、构建、单元测试、分析、集成、集成测试、打包、Place、压力测试、验收测试、发布、部署、监控
  其中的构建和编译、单元测试并列，不清楚这里的构建表示什么？我理解的构建时编译、打包、或者在加上单元测试、代码分析的整体。自动化构建的目标就是要输出（高质量）可以部署和测试的软件包。
  另外，关于Place也没有找到对应的解释，有点像部署或者分发
• 环境
• 开发环境
• 预发布环境（类生产环境）
• 生产环境
  关键中缺少独立的测试环境，从图上的分布看，应该是包含在Development中的
• 方法
• 敏捷
  「对特性进行识别、排序、调整的增量开发方法」。不太理解，敏捷的具体方法框架有很多，包括Scrum，XP，Kanban（准确的说属于精益方法）。还有 SAFe，Less 等规模化框架。
• 持续集成
  持续集成是持续交付的基础，持续交付是 DevOps 的核心工程实践。非常重要。
• 持续交付
• 持续部署另外，红色框的逻辑没有理解明白，有高手请指点。
  
  

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 还有很长的路要走。企业级的改进需要组织、文化都要共同变化。

6.4 改进四象限

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

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

6.5 改进路径与模式

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

路径一：

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

路径二：

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

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

· 自下而上的改进

这种模式应该是比较常见

· 自上而下的改进

6.6 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 架构与实现技术

• 特性开关
• 灰度发布
• 微服务
  以上三个技术对发布和部署都有很大的提升，特性开关可以调整应用的运用时状态，灰度发布逐步的切换流量，微服务可以做到单个服务的独立发布和部署。
• 基础设施技术
• 蓝绿部署
• 金丝雀发布
• 凤凰环境
• 不可变基础设施
  
  

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

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

8、DevOps 黄金思维圈

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

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

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

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

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

What：

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

（转自DevOps持续交付）

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

重点内容：

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 是一组文化方法和技术实践。

维度：

• 阶段：产品定义、计划、编码、编译、构建、单元测试、分析、集成、集成测试、打包、Place、压力测试、验收测试、发布、部署、监控
  其中的构建和编译、单元测试并列，不清楚这里的构建表示什么？我理解的构建时编译、打包、或者在加上单元测试、代码分析的整体。自动化构建的目标就是要输出（高质量）可以部署和测试的软件包。
  另外，关于Place也没有找到对应的解释，有点像部署或者分发
• 环境
• 开发环境
• 预发布环境（类生产环境）
• 生产环境
  关键中缺少独立的测试环境，从图上的分布看，应该是包含在Development中的
• 方法
• 敏捷
  「对特性进行识别、排序、调整的增量开发方法」。不太理解，敏捷的具体方法框架有很多，包括Scrum，XP，Kanban（准确的说属于精益方法）。还有 SAFe，Less 等规模化框架。
• 持续集成
  持续集成是持续交付的基础，持续交付是 DevOps 的核心工程实践。非常重要。
• 持续交付
• 持续部署另外，红色框的逻辑没有理解明白，有高手请指点。
  
  

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 还有很长的路要走。企业级的改进需要组织、文化都要共同变化。

6.4 改进四象限

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

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

6.5 改进路径与模式

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

路径一：

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

路径二：

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

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

· 自下而上的改进

这种模式应该是比较常见

· 自上而下的改进

6.6 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 架构与实现技术

• 特性开关
• 灰度发布
• 微服务
  以上三个技术对发布和部署都有很大的提升，特性开关可以调整应用的运用时状态，灰度发布逐步的切换流量，微服务可以做到单个服务的独立发布和部署。
• 基础设施技术
• 蓝绿部署
• 金丝雀发布
• 凤凰环境
• 不可变基础设施
  
  

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

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

8、DevOps 黄金思维圈

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

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

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

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

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

What：

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

（转自DevOps持续交付）