持续交付2.0：业务引领的DevOps精要（增订本）

持续交付2.0=精益创业+持续交付1.0=价值探索+快速验证 在书中，不仅可以收获 2.0 双环模型、实施原则、案例分享，也有诸如「某姓网无法合并的分支」之类的“鬼故事”，还有「别走得太快，等一等灵魂」之类的哲理小故事。 全书干货满满，又不失生（ou）动（er）有（ba）趣（gua）。 推荐翻翻，让灵魂跟上你的脚步？[旺柴]

软件这种复杂系统，越多人参与协作，个体平均效率就越低。软件工程从最初的瀑布模型发展到敏捷开发和 DevOps 解决的就是如何通过合理地管理软件系统的复杂性以及软件生产运营流程的复杂性来提升组织效率。持续交付以部署流水线的模式高质量低风险地快速发布软件价值。

面对复杂的大型软件，会面临如何又快又好完成持续交付的困境，几乎是每个IT公司不可回避的问题。作者以丰富的经验列举了大量案例，确实能解惑，但实践才能出真知，一起践行吧，共勉。

对日常工作的优化要比日常工作本身更为重要，软件研发要做到高效的过程管理是一个巨大的挑战，不同人亦有不同的见解和做法：Scrum、LeSS、Kanban、SAFes、Devops等思想层出不穷，但无一模式可放之四海皆准，核心在于对现有组织文化和过程问题的分析和洞察，在思想指导下采用本地化的策略和节奏。 有幸和乔梁老师在腾讯共事两年，并对书中模式进行深度实践，效果和反馈均很好，个人亦受益匪浅。深感从简单的问题开始持续改善，识别和消除过程浪费恰是核心。 入职新公司三年，现如今也到了再提研发变革的时机，故再度翻出本书精读了两遍。时过境迁，心境和目的，团队和文化大相径庭，难度更大但信心和兴奋依然在。 习惯的改变是一个艰难和痛苦的过程，希望本书可以帮你克服惰性和恐惧，所有成长和收获。

整体而言，本书有点虎头蛇尾 前几章能够把精益思想与持续交付思想相结合，这是一大亮点 后面几章（11章-13章）摊子铺太大，面很广但都不深入，蜻蜓点水，其中一些理念在某些行业中应用是错误的： 比如第11章对于软件配置管理的描述要分场景来看待，在智能硬件领域，比如汽车，自动驾驶，手机，芯片等场景中，整个软件系统由几十上百个模块组成，书中所讲的“用显式版本号相互依赖”是错误的做法，应该参考安卓系统对于组件的管理方式。 正确的原则：禁止系统中所有组件之间通过显式的版本号决定依赖关系。任意两个或者多个模块之间是否匹配，只取决于把它们集成后“编译通过+自动化测试通过”，而不取决于“显示的版本号依赖关系”。这条原则非常重要，组件越多，越要这么做，从而降低任意一个组件升级的难度 第17章“研发效能提升的必经之路”，看似治本，实则治标。 绝大部分的公司的研发效能低的源头在于官僚机构养了太多人，而不在于自动化程度太低。为一个庞大的官僚机构增加自动化和一致性，并不能解决研发效能低的问题，通过自动化节省的人力资源和时间会继续消耗在“开会，复盘，学习，斗争”等无意义的事情上。比如：微软，BAT，等大公司内部，自动化和一致性肯定都是非常优秀的，但是人效却是不高的。 正确的做法：从源头把人员精简到位，同时辅以自动化工具链建设。“控制人员精简+不断提升人才密度”，这些才是根本。自动化手段只是辅助 第17章中强调加强code review，这个理念是错误的，任何不依赖于自动化工具的措施都无法保证落地质量。code review应该用静态扫描工具全面代替，几个方法： 1. 使用行业成熟的静态扫描工具，precision和recall都堪忧。。。 2. 自研静态扫描工具，这是最佳路径； 3. 利用好chatgpt等AI，对企业人才要求很高，要把扫描结果做到稳定不容易

全书共包括3部分内容：第一部分会介绍“持续交付2.0”的双环模型；第二部分主要讨论使用“持续交付2.0”框架时可能遇到的问题，以及改进过程中需要遵循的原则；第三部分主要是案例分享，目的是让读者体会在持续改善过程中，不同企业和团队的实施重点与解决方案的不同。下面我们一起浏览一下各章的具体内容。 第一部分主要讲述“持续交付2.0”双环模型（即持续交付“8”字环）和“持续交付2.0”的4个工作原则，还会介绍两个闭环“价值探索”与“快速验证”的执行步骤与相关原则。 第1章讨论持续交付的发展必然性，并介绍“持续交付2.0双环模型”及其4个基本原则。 第2章讨论“价值探索环”（简称“探索环”）的4个关键环节，以及每个环节的指导原则与实践方法。只有业务方能够以“精益”方式思考，持续交付才能更显威力，否则很可能退缩成为持续交付1.0的单环模式，即只有“快速验证环”。 第3章简单阐述“快速验证环”（简称“验证环”）中各环节的主要活动，并给出各环节的工作方法。 第二部分主要阐述“持续交付2.0”的实施七巧板中，三大主要板块的工作原则与实践方法。这三大板块包括组织机制、软件架构与基础设施。其中组织机制是一个复杂课题，本书仅讨论持续交付所需的文化，以及塑造文化的四步法。组织架构、人才结构、激励机制等内容将在本书的续篇中专题讨论。基础设施部分是产品研发过程中最基础的工作。这部分首先讨论持续交付部署流水线及其工具设计原则，然后分别介绍部署流水线的建立与优化必须关注的五大领域，也就是说，业务需求协作流程、分支与配置管理、构建与环境管理、自动化测试管理以及部署发布与监控管理。 第4章讨论持续交付能力的提升需要企业具有安全、信任与持续改善的组织文化，并介绍丰田公司和谷歌公司用过的组织文化塑造四步法。 第5章讨论软件架构对实现持续交付快速验证能力的重要性、有利于持续交付的软件架构特征，以及软件架构改造的3种模式，即“拆迁”“绞杀”和“修缮”。 第6章讨论如何利用约束理论和精益思想发现流程中的瓶颈，使各角色之间的业务需求协作更加顺畅，提升需求流动速度。 第7章讨论快速验证环所依赖的部署流水线的设计原则与工具链建设草案。 第8章讨论代码仓库的分支方式对持续交付的重大影响，以及不同分支方式下部署流水线的建设方案，最后介绍代码分支的数量对发布策略的影响。 第9章回顾持续集成的历史，并讲解如何判断团队是否在实践持续集成，还给出企业实施持续集成实践的五大步骤。 第10章讨论软件发布以前制订自动化测试策略需要考虑的因素，还介绍持续集成对自动化测试用例的编写与运行要求。最后介绍为了提高自动化测试的投资回报率，团队如何为遗留系统编写和增加自动化测试用例。 第11章讨论软件配置管理，它是持续交付快速验证环的基础。对代码、配置、环境、数据做好配置管理，最终实现一键部署和一键测试，让各角色在协作过程中能够全部实现自动化服务，并且互不影响，解放人的大脑和双手，做更有价值的事情，而让机器做它擅长的事——不断地重复。 第12章讨论降低生产部署与发布风险的技术与方法。 第13章讨论软件在运行时进行数据收集与分析的重要性，以及衡量数据监测环节的衡量指标，包括正确性、完整性和及时性，此外，还介绍测试活动扁平化趋势，以及生产环境上的质量巡检与演习。 第三部分主要是实战案例的分析。它们分别代表不同类型的公司、不同大小的团队以及不同的软件产品特点。我将带你深入案例现场，了解当时状况，分析问题，并提出解决思路。 第14章介绍一个百人工程师的互联网产品团队历经一年时间，如何打造快速运转的“持续交付2.0双环模型”，并且做到可持续运转。 第15章介绍在无法“测试右移”的情况下，一个大项目中的小团队如何改变团队协作模式，从“死亡行军”转变为无缺陷交付。 第16章介绍一个微服务化开发团队如何在项目运行的过程中，通过逐步对基础设施板块中各模块进行改造，提升交付质量与频率，并推动运维人员也做出改变，真正成为一个“DevOps团队”。 第17章介绍提升组织效能的关键点和启动时机，提供一个关于产品研发胜任力的评估框架并给出相关说明。

本书可以作为持续交付的入门必读工具书。 持续交付双循环：探索环和验证环。 探索环：4个可持续循环步骤，分别是提问、锚定、共创和精炼。 验证环：4个可持续循环的步骤，分别是构建、运行、监测和决策。 持续交付交付七巧板：基础设施，软件架构，组织机制。

DevOps是一种软件工程文化和实践，旨在统一整合软件开发和软件运维。DevOps运动的主要特点是强烈倡导对构建软件的所有环节（从集成、测试、发布到部署和基础架构管理）进行全面的自动化和监控。DevOps的目标是缩短开发周期，提高部署频率和更可靠地发布，与业务目标保持一致。

以前理解的持续交付以为是将大的瀑布过程才拆分为小的，借助于cicd工具，进行交付过程，本书描述的持续交付2.0，已经不再局限于此，在项目初期就已经对需求进行满足要求的评估和拆分 ，测试人员已经编写并通过了测试用例评估，开发人员在完成某一个功能点后，对该功能点进行ut和自测并成功运行自动化测试后，就可交给测试人员验证，一旦在各个环境通过验证，便可进行发布，既减少了发布风险，又提高了交付速度，使得需求得到更快的验证和反馈，不过这种方式目前我还没参与过，对人员素质要求，平台工具要求和整个流程要求比较高。

这本书对于比较传统的公司可能借鉴意义更大，对于身处科技行业早就熟练 SCRUM 的团队来说，参考意义有限。选感兴趣的章节，随便翻阅一下即可。