Jenkins创始人Kohsuke Kawaguchi(KK)于2004年开发了 Jenkins 项目的前身(Hudson),一开始就是为了解决他自己的关于自动化的需求。他自己也没想到15年后,Jenkins 成了软件交付过程中的核心工具,驱动着千万企业的持续交付与 DevOps 过程。 这次主题演讲KK系统的分析了持续交付与 DevOps 的体系、现状、路线图和模式,和 Patrick 在 DevOpsDays · 北京站的演讲一样,大神为我们点亮了命星! 整理的重点内容: 1. 持续交付框架分析 1、流程线已经改变过一次世界福特在引入流水线生产之后,Model-T 的组装时间缩短了8倍。1.3万名员工生产了30万量汽车,超过了300家竞争对手的总和,这就是效率的神话。 不过后来丰田超越了福特,在不确定性越来越突出的现在,单纯的效率已经不能满足企业的竞争,所以精益、敏捷、DevOps 才会出现,继续探索软件开发新模式、拓展效率和质量的新边疆。 2、软件正在吞噬世界这个是共识,这是全人类的挑战和机遇,对我们从事工程效率和过程改进的人来说,不断改进软件交付的方式和效率,没有止境。 3、头号需求:业务连续性(不停机)各大权威机构对 IT、DevOps、Continuous Delivery 的预测和评估。 我认为业务连续性也只是其中一项需求而已,整体上来讲,我们要解决的两个问题是:Build the things right and Build the right things。
4、持续交付框架分析KK 的持续交付相关内容梳理的很清晰。这张图也可以说是 DevOps 的管理与工程实践框架。KK 也强调了 DevOps 是一组文化方法和技术实践。 维度:
5、生存还是毁灭,你可以选择每年的 State of DevOps Report 都会公布四个关键指标的数据:部署频率、周期时间、部署失败率、故障修复时间。高效能IT组织和低效能IT组织的差异非常大。KK的这两张图也非常形象的说明了这个问题。 6、现状和方向6.1 敏捷团队占比现状是上游敏捷(管理过程,比如Scrum)的团队占比33%,下游敏捷(持续交付)的团队占比13%。
我认为持续集成和自动化测试是敏捷的两条腿,想要敏捷跑起来,此二者必须同时建设才能让敏捷体现其快速响应变化的价值。 6.2 非敏捷团队占比根据 KK 的数据,目前有87%的团队,依然没有实现下游的敏捷,即持续交付和持续部署的实施较少或者不成熟。这会导致价值的交付依然长达数月之久。 6.3 成熟度级别KK 将敏捷(CD、DevOps)的级别划分为团队级,跨团队级,企业级。这个和 DevOps 之父 Patrick 的 DevOps 5个精进级别颇为相似。 企业级的敏捷和 DevOps 还有很长的路要走。企业级的改进需要组织、文化都要共同变化。
6.4 改进四象限KK 基于团队级、跨团队级、企业级以及上下游阶段,将改进方向划分为四个象限。
6.5 改进路径与模式KK 基于四象限将改进划分为2条路径和2种模式 路径一:从团队敏捷到企业级(组织级)敏捷,再到企业级 DevOps 路径二:团队级敏捷—>团队级持续交付—>企业级敏捷—>企业级 DevOps 我所了解的企业,偏向于类似第二种的路径,一开始都在团队级别进行敏捷和持续交付的尝试,逐渐成熟推广复用,规模化。 · 自下而上的改进这种模式应该是比较常见 · 自上而下的改进6.6 DevOps转型策略KK给出了自己的建议: 1. 识别试点项目 关于第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:
How: What: 1. 每次代码提交都需要经过流水线验证 |
|