持续交付：发布可靠软件的系统方法

1.极其全面阐述《持续交付》的一本书，包含从代码提交到发布上线全过程的要点、最佳实践和细节讨论，能够使人读后建立一个系统化的认知。 2.由于此，阅读本书显得很费力，因为细节非常之多。所以可以选择性阅读第一章和第五章、第十五章，形成整体认知后，快速浏览其他章节，至于很细节的内容就作为工具书使用了。 3.核心：a。为什么要做持续交付？本质目的是尽早及时持续交付价值，使得客户满意；b，持续交付的衡量指标？可用版本的cycle time，即客户用户故事确认到最终可以体验或使用所需要的时间。这是核心竞争力；c，关键原则是什么？正如持续交付中的持续所言，必须遵从不断交付的原则，遇到的问题都应该想办法解决，而非放弃这一原则；d，哪些因素影响持续交付？重要因素有七个：采用的组织治理模式，比如是否采用敏捷开发模式，开发、测试、运维人员是否融合在一起，还是说处于零和博弈状态；版本控制模式，最佳的方式是分支开发、主干发布，使用DVCS这种版本控制系统达到既实现并行高效开发，又频繁合并实现持续交付；测试策略，是否采用了自动化测试；技术架构，是否使用了松耦合的架构，比如微服务；部署模型，是否采用了AB测试、灰度上线等可以允许发布代码直接上线的实践；基础设施，使用采用与应用相对解耦的基础设施管理，甚至剥离其关系，尤其是IaaS和PaaS的采用，使得基础设施不再费时；数据库，是否做到有效的数据管理，减少对数据的依赖。

非常厚实的一本书。概述持续集成与持续交付，然后开始按照各个板块进行分述。具体内容详见目录。 整本书读完，我并并没有很懂。因为这本书实在太“厚实”了。本书主要围绕软件交付这一软件生命周期的关键步骤进行论述。分析软件交付的问题，持续集成，测试，研发策略，团队管理，部署配置管理，团队管理等多方面的内容。 核心思想在于持续交付可运行的的软件版本。 本书提倡： 高频持续集成， 尽快获得集成反馈， 立刻修复集成检测发现的缺陷， 高度自动化管理避免人为错误， ... 全书还有大量优秀的指导思想需要通过持续学习与实践才能习得。第一次阅读就先收下这些。

虽然这本书作者十年前就写成了，但是今天读起来也不过时，因为很多理论基本上今天还在指导实践。 我大概阅读了一遍，感觉本书内容丰富，作者知识面广，很多思想可以直接吸收使用，总之是一本不错的工具书，可以时常翻翻。

在不当build release engineer的第七年，我又重新读了一遍这本书，收获还是满满，作者用自己的实践介绍了从设计到部署中的最佳实践，总结的经验教训几乎每个我都认同，可以作为ops工程师的圣经、虽然他已经是7，8年前写出来的了

原书的确是一本很经典的CI/CD的工程能效知识书籍，只可惜中文版本翻译的的确太差... 令人时常读起来搞不清楚状况，但翻一下原文就很清楚，甚至有时候还出现翻译错误的情况。翻译要讲究一个信、雅、达... 既是对原书作者的尊重，也是对读者的尊重，更是对知识的尊重... 特别是技术类书籍，来不得半点马虎... 希望以后能看到重译的版本。

一本关注如何降低发布风险和加快发布速度的书籍，我觉得持续集成和持续交付的概念其实比较简单也比较好理解，但是第一个能提出这个概念并不容易，如果你没有管理大型系统的经验，没有为发布风险承担巨大的上级压力的话，或者没有管理多个集群和分布式系统的经验的话，发布这件事对你来说并不是一个问题，因为问题还没有大到难以忍受，所以维持现状通过传统的手工发布似乎还凑活地过日子。其实当时意识要控制发布风险来降低手工失误时，你就会考虑去写一个自动化的部署脚本。当你面对众多主机，每一部分主机需要发布不同应用程序时，你就会考虑一键部署工具。为了避免将明显的错误带入版本控制系统，你就会考虑写一写自动化的测试来降低测试人员花在回归测试上的时间，让他们能专注于探索性测试和可用性测试。为了降低最终上线发布的影响范围，你会考虑使用金丝雀发布的方式，做到进可攻(逐渐过渡)退可守(一键回滚)，个人感觉蓝绿部署和金丝雀发布类似，只是前者没有后者平滑，一个是全部引导，一个是小部分引导。除此源码之外，作者还提到软件的运行环境(基础设施)也需要版本控制，做到让环境的重建成本为0，可以通过虚拟镜像的方式，同时还要求对基础设施环境的变更要记录在案，要有访问控制。对于配置信息，作者也提到需要单独的配置管理服务来对所有应用程序的不同版本在不同环境的配置信息做版本控制，即(应用程序的类型，应用程序的版本号，环境) –> 单独的配置信息。本书的核心思想 –> 通过自动化的方式来降低手工风险和加快流程，所有的操作都要有版本控制，支持一键后悔。(作者常说的，我们要实现构建、测试、部署、发布的全自动化)

读了一个月，终于读完了这本书。对于软件开发的整个流程，终于有了一定的认识。很佩服作者提出的关于“持续交付”的种种思想与解决方案，于我来说，犹如拨云见日。很赞成书中的一个观点：团队的结构与成员间的交流方式，会反应到项目的结构与质量上。

书中涉及持续交付中配置、环境、构建、测试、部署等各个环节，很全面很详细。第二部分讲了很多关于自动化测试方面。时间紧的话可以着重看第一部分和第三部分。 第三部分中，对数据库管理、代码版本，依赖管理需要再阅读其他书籍。 在现在DevOps、云原生架构流行的情况下，持续交付的方式可能会有些许的不同，但是对项目管理的各个环节万变不离其宗，需基于各个原则进行实践。

DevOps，概言之，使开发运维自动化。 开发者，开发功能；运维者，维持稳定。 持续交付，快速反馈，迭代增量。 “我们还能与家人和朋友共度周末，享受没有压力的生活，而工作也会变得更加高效。为什么不呢？生命如此短暂，我们不能把自己的假期浪费在计算机旁，做那些枯燥无味的部署工作。”

内容充实，层次感强。从顶层方法论开始逐步细化说明持续交付的概念，配合一些实际案例更容易体会和理解。二刷结束