《持续交付2.0 业务引领的DevOps精要（增订本）》一书深入探讨了DevOps在业务引领方面的精髓。文章指出，持续交付是一个持续演进的过程，通过快速交付新功能和增量改进，实现业务的快速响应和创新。作者还提出了一系列实践和原则，如自动化测试、持续集成和部署等，帮助企业实现高效的软件交付。这本书对于理解和应用DevOps的实践价值具有重要的参考意义。
持续交付2.0 业务引领的DevOps精要（增订本）读后感第一篇
相信有的读者朋友们开始也是跟我一样对于什么是持续交付并没有什么概念，本书首先对持续交付的发展做了介绍，从瀑布软件开发和敏捷开发引入DevOPs的概念，进而介绍了DevOps1.0到DevOps2.0的发展历程。我们做软件开发的一定对瀑布开发和敏捷开发很熟悉，那么我从这个角度去进一步理解DevOps的概念，相对来说就比较有切入点了。所以我们从开始对这个概念有了大致的认识，那么就可以抽丝剥茧的去学习挖掘这个对于我来说还没有完全接触过的新知识。
在本书中作者共分了17个章节。从价值意义到软件架构系统，再到流水线工具设计/服务器云化，一直到利于集成的分支策略再到最后的持续集成及软件配置管理，整个软件开发部署环境，包括需求，开发，测试，整个实施过程完整性的展示到了读者跟前。最后在其他的风险和管理角度作者又进行了方法总结。
个人对持续交付的软件系统架构印象较深，在本章中作者定义了“大系统小做”的原则，常见的架构模式以及架构改造实施模式。从当前大型的互联网项目来说我们最常见的还是微服务架构，它提倡将单一的应用程序划分为一组小服务，服务之间相互配合相互协调，为整个系统系统有序的价值输出。当然这在DevOps中只是一环，然后在架构模式确定之后，根据需求进行故事的拆解，进入研发和测试环节，最后到系统版本发布，运营等等一系列的操作，分级实现需求逐步交付，才能算完成完善整个交付过程。
个人理解从初读本书前后不太好把整个知识链整合到一起，涉及到的内容点比较多，需要细读并且不断的总结回顾，真正完成这些之后然后再运用到实际的工作中，我相信是获益匪浅的。
持续交付2.0 业务引领的DevOps精要（增订本）读后感第二篇
阅读过本书2018版，这次的增订版，除了在内容上有所调整，另外增加了一个新的章节《研发组织效能提升的必经之路》。在这里，就针对这个章节做一点补充和分享。
在这一部分，作者分享了展现企业组织能力的三个基本要素，包括流程机制、工具平台和个体能力。这三部分，共同推动着组织持续交付能力的提升。
其中，流程机制，包括产品研发流程细节，操作标准，各环节的衔接方式以及交付标准。团队通过推动研发流程细节的不断优化，操作流程中问题的持续改进，来推动产品研发交付质量和效率的提升。
工具平台，是支持产品研发过程不断提升的载体，通过打造支持产品研发效率提高的工具，利用平台承载更多有效的数据和信息，来帮助产品研发的提高。
个体能力，则是指产品研发团队每个个体的能力，包括如何提高自己在研发流程中提高自己的输出质量，在研发流程中更好的发挥自己的价值，与整个团队进行磨合等，更强的能力，更好的配合度和适应能力，能够让他在团队和研发流程中更好的发挥自己的价值和作用。
这三部分不能割裂开来，三者持续推动，相互辅助，才能推动产品研发流程和组织交付能力持续提高。单一提高某一项，并不能带来更好的整体提升。
而在这个过程中，持续的观察和识别组织遇到和暴露的问题，通过将问题具象化，以恰当的方式度量，提出行之有效的方式推动改进，并通过度量结果进行佐证和进一步的改进，来更好的推动组织能力的提升，这些也是组织能力提升的最佳实践。
此外，在这一部分，作者还提出了组织胜任力评估的两个维度：过程维度和结果维度。
过程维度，主要包括一些具有引导属性的指标。组织通过这些指标的提出，给予成员努力改进的方向，从而为提高团队整体水平做牵引。
但在这一过程中，需要避免指标重要性的偏颇，以免团队为了达成某一个或几个指标，而忽略了其他指标的作用；或在某一个或几个指标的投入过于巨大，而产出不对等的情况。
结果维度，是具有结果性的指标，主要包括质量、速度和吞吐率。用这些指标来度量整个组织的研发情况。
其中，质量，包括交付前的过程质量、交付后的生产质量；速度，包括业务需求的杨颖速度、团队的持续交付能力；吞吐率，则是指单位时间内的价值产出。
通过这几个方面的度量，来考察团队交付结果的情况。
以上，希望可以给大家带来一点思考和价值。
持续交付2.0 业务引领的DevOps精要（增订本）读后感第三篇
两年前看了乔梁编写的《持续交付2.0》，收获颇多，还写了一篇读书笔记，今年 2 月，该书出了增订本，增加了一个章节的内容，其他的一些章节内容也有局部的优化。
花了一个多星期，翻阅了这本增定本，就像在之前读书笔记中说的，好书是常读常新的，每次都会带来新的收获和思考，取决于你当下的认知和期望能解决的问题。
新增的第 17 章主要在讲研发组织的效能提升，从软件的复杂度，谈到了产品研发的胜任力模型到最后的组织健康度，在一个比较抽象的层面给我们打开了思路，因为篇幅的原因，没有展开讲。
相比新增的章节，我重新看的过程中发现低风险发布是我最感兴趣的，我们现在的产品正在进行 SaaS 化改造，上线后就会面临着持续发布的问题，这里面的内容正好用得上。
下面说几个我们遇到的问题以及按照书中的思路应该怎么去解决：
1、发布上线，怎样保证稳定性？
通常我们发布上线，就是停机发布，发布后，所有的人看到的都是最新的版本。这样其实风险是比较高的，风险有两个方面，一是生产环境和测试环境总会有些差异，有时在测试环境没有问题到生产会出现问题；二是程序上有缺陷会影响到所有的用户。
下面有几种低风险的发布方式：
蓝绿部署：
假设现在有一个生产环境 A，再准备一套和这个生产环境完全一致的环境 B，其中 A 对外提供服务，B 作为预发布环境。
发布时，发布到 B 环境，可以在这个环境上做一些测试验证，没有问题后，将 B 对外提供服务，A 作为下一次的预发布环境，如此循环。
这种方式有个问题就是需要考虑到数据库，如果两个环境使用一个数据库，就需要处理两个不同版本的兼容性问题；如果每个环境都有自己的数据库，那么在两个环境进行切换时，可能会存在数据不一致的问题。
灰度发布：
一个新功能上线，让一部分人先使用，然后陆续开放给所有用户。如有问题，只会影响到一小部分用户。
很多互联网公司采用这种方式来验证一个新的功能是否受欢迎。微信发布新功能，很多时候也是采用灰度的方式。
在部署时，可以先只更新其中的某些节点，那么负载到这些节点的用户看到的就是新的内容，其他节点的还是之前的内容，至于谁能看到这些新的内容，在网关层可以根据 IP、区域、特定用户等来进行负载，具体看业务场景了。
滚动发布：
一个集群中有很多个节点，选择其中一个停止服务，进行更新，更新完后将其投入使用，依次将所有的节点更新完。
我们现在有一个客户每次升级就是采用这种方式，对用户来说几乎是无感知的，因为一个节点在进行升级的时候，其他的节点依然能够提供服务。
但有一个点需要注意，就是如果版本更新较大涉及到了数据库结构的改动，需要做兼容性处理。
2、产品进行大规模的重构时，常规功能怎样同时进行？
去年我们就经历过一次比较大的重构，主要做了很多的代码结构的调整，提升程序的性能，而在这个期间，几乎没有做常规功能的迭代，我们的做法就是以当前发布分支拉取一个优化分支进行代码修改，发布分支上只做些 Bug 修复，修复完后就及时合并到优化分支，最后优化完成，再合并到发布分支。
而我们想要的是一边做常规功能，一边进行优化。
首先分析进行重构的部分是不是能够进行拆解，如果能够拆分成一些小的独立的部分，就可以安排在迭代内完成并和常规功能一起发布上线。
很多时候，重构优化涉及的模块非常多，这时就可以引入中间层，加上开关控制，新的逻辑和老的逻辑同时存在，逐步替换，等到所有的都替换完后，再将老的逻辑删除。
唯一不足的就是重构的周期会比较长。
3、在一个迭代周期内，前后端的任务总是不能吻合地很好，应该怎么办？
这里说的吻合是指在一个迭代中前端和后端的任务量相当，同时结束工作，同时开始下一迭代。以我们这半年实践敏捷开发发现，这种理想状况很难。
我们现在的模式是三周迭代，以目前的能力无法做到每个开发人员的任务安排到最后一天，因为最后几天测试人员要进行整体回归测试。这就存在一个衔接的问题，开发人员在当前迭代的任务结束了，但迭代周期没有结束，那么开发人员应该做什么？
关于这个问题，我跟领导沟通过很多次，最近也咨询了一家大公司的产品团队负责人，再加上本书中的讲解，我大致总结了下：
这是第二次读这本书，但我相信不会是最后一次。
