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 是一组文化方法和技术实践。
维度:
- 阶段:产品定义、计划、编码、编译、构建、单元测试、分析、集成、集成测试、打包、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 还有很长的路要走。企业级的改进需要组织、文化都要共同变化。
编者:之前在参加敏捷培训时,老师提到诺西在敏捷方面做的很早也很深入,摩托做 CMMI 和 6 Sigma 也做的很好,但是这些企业现在都不在了。组织、战略、文化的敏捷至关重要。下边的人玩儿的很嗨,只是用正确的方法在做错误的事情而已。颇有感触!
6.4改进四象限
KK 基于团队级、跨团队级、企业级以及上下游阶段,将改进方向划分为四个象限。
1. 团队级的敏捷 2. 团队级的CD 3. 企业级的敏捷 4. 企业级的DevOps(我相信2017和2018年,国内企业一定会迈进企业级的DevOps转型和落地)
6.5改进路径与模式
KK 基于四象限将改进划分为2条路径和2种模式
路径一:
从团队敏捷到企业级(组织级)敏捷,再到企业级 DevOps
路径二:
团队级敏捷—>团队级持续交付—>企业级敏捷—>企业级 DevOps
我所了解的企业,偏向于类似第二种的路径,一开始都在团队级别进行敏捷和持续交付的尝试,逐渐成熟推广复用,规模化
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 过程中的思考和记录,没到现场,所以感觉很零散。恰好最近刚接触一个概念:黄金思维圈,如下图所示:
感谢您的来访,获取更多精彩文章请收藏本站。
![](https://www.gyzsq.com/wp-content/uploads/2022/07/9259adea4619.gif)
1 本站一切资源不代表本站立场,并不代表本站赞同其观点和对其真实性负责。
2 本站一律禁止以任何方式发布或转载任何违法的相关信息,访客发现请向站长举报
3 本站资源大多存储在云盘,如发现链接失效,请联系我们我们会第一时间更新。
![头像](/wp-content/themes/zibll/img/avatar-default.png)
- 最新
- 最热
查看全部没有评论内容