《持续交付》是一本由Jez Humble / David Farley著作，人民邮电出版社出版的平装图书，本书定价：89.00元，页数：362，特精心从网络上整理的一些读者的读后感，希望对大家能有帮助。

　　《持续交付》读后感(一)：值得一读

　　中文翻译比较流程，偶尔一些地方与英文不一致，可以配合英文读或者直接读原版。总的来说，值得一读。　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　

　　《持续交付》读后感(二)：简介

　　第一部分

　　持续交付，加强开发团队、测试团队、运维团队、产品团队之间的沟通，以达到及早的发现问题的目的。

　　如何实现持续交付：配置管理，持续集成，测试策略

　　测试贯穿始终 -> 建立反馈环

　　第二部分

　　详细介绍部署流水线的每个阶段，并提供每个阶段的一些可供参考的策略。

　　第三部分

　　支持部署流水线的相关技术。包括：基础环境，数据管理，依赖管理，版本控制。

　　《持续交付》读后感(三)：持续反馈，延伸至更多的环节

　　好书，今年在项目中很多的精神和实践都来源于此书。

　　CI给与了团队内部的及时反馈，而CD将反馈循环拉大到了对客户的交付。 这是广义上DevOps运动的需要，也迎合了真价值交付的敏捷精髓。

　　DevOps运动员的5星推荐！

　　《持续交付》读后感(四)：持续自动化

　　我是“好的程序员的生产力十倍于差的程序员”这句话的信奉者，由此我期望的未来会有很多人数很少但精锐的小的软件开发组织存在。要在这样的未来生存，需要把一切能够自动化的事务都自动化，让宝贵的智力专注在最有价值的业务上。

　　同时作为一个在大型互联网公司工作过数年的开发者，配置管理、部署和运维的复杂和困难另我深感敬畏，这种困难告诉我在开发和运维之间存在“失落的一环”，在这个弱点得到弥补之前，好的程序员也无法充分发挥其生产力。

　　这本持续交付正是讲述了怎么弥补这失落的一环，把开发、提交、自动化测试、持续集成、自动化部署完整的串了起来。

　　另外，infrastructure as code是非常强大的概念，必须学习。

　　《持续交付》读后感(五)：废话多 干货少

　　本书废话多而干货少，罗里啰嗦地把几项持续集成、持续交付的原则翻来覆去地重复个没完！而且乏味理论多、结合实例少，估计对没有Build & Release流程经验的软件工程师而言，不知道作者在讲些什么，还不如参加公司的内部培训讲座有用。

　　本书冗余重复的内容至少可以压缩掉一半，而书价定在RMB ￥89，真够贵的！

　　结合自己的经验记录下读书笔记：

　　一键式发布：构建、部署、测试和发布应用程序流程的自动化，

　　将构建、部署、测试和发布软件所需的东西，如配置文件、DB脚本、构建脚本，测试用具全部版本控制。

　　持续集成：SVN + Hudson/Jenkins + Ant/Python

　　自动化测试: JUnit、FindBugs、PMD、CheckStyle、Cobertura; gtest、CppCheck、gcovr; Sonar

　　一键式部署: 这个我觉得没有通用工具，需要各家公司根据自己实际需求自己开发内部部署工具。

　　《持续交付》读后感(六)：老酒翻新-DevOps基础

　　2011年10月国内第一次印刷，2016年DevOps在IT圈内火了以后，很多人都在重新经典。本书的作者及翻译者原来是一家外企公司，在一起工作，持续交付作为他们的实践被总结出来，并且从一开始就影响着互联网，国内大的互联网企业都在应用此方法。

　　2016年我看了此书好几遍，感觉很多方法现在依然不落后，并且有很高的实用价值。并且此书已经DevOps Master课程列为基础读物。

　　2017年3月与此书翻译者见面，并聆听他的理解，以客户为起点，为客户交付价值才是真正实现持续交付。国内很多的看书有很多误解，希望能更新。

　　老李看持续交付

　　《持续交付》读后感(七)：从持续集成到持续交付

　　毫无疑问，这本书是敏捷软件开发领域的又一本巨著。“在你的组织里，仅涉及一行代码的改动，需要多长时间才能部署上线？你的处理方式是否可重复且可靠？” 本书就是针对这个问题给出的解决方案，如果对比下当下大多数项目的现状，你会发现差距好远。本书的优点在于它不仅为你指出的一个理想的“持续交付”目标和达成“持续交付”目标的系统方法，而且字里行间交代了许多实现中会遇到的问题，有些问题是我们遇到并用类似的方法解决过的，我们看到的时候会会心一笑，有些问题是我们至今感到苦恼的，读到的时候，我们就会恍然大悟。这些都说明作者不是空谈，而是多年积累的结晶。另外，个人建议先有一定的持续集成经验，再来读这本书会更有收获些。

　　下面摘录些本书中给我以启发和共鸣的思想、方法、以及具体实践：

　　1. 提前并频繁的做让你感到痛苦的事情，直到它变得不再痛苦。

　　2. 每次修改必须触发反馈流程，反馈要足够快，团队必须接受反馈，并做出相应行动。

　　3. 所有东西都应纳入版本控制：源码、测试脚本、测试用例、部署脚本等等。

　　4.构建失败，则不能提交新代码。持续集成变红不能过夜，要么快速解决，要么回退。

　　5. 通过预测试提交（pretested commit）可以有效减少提交导致的持续集成变红情况。

　　6.部署流水线，自动化的软件交付流程：提交阶段、自动化验收测试、用户验收测试、部署与发布。

　　7.组件与库的依赖关系：通过依赖关系，建立以组件流水线为基础的集成流水线。

　　8.分支管理：建议主干开发模式，只有针对发布可以创建分支，分支上只允许提交严重故障的修复，并且必须马上合并回主干。避免使用“长生命周期的分支"。

　　《持续交付》读后感(八)：持续集成，持续部署，持续交付

　　我英文版看了前一半，中文版看了剩下的另一半。翻译的质量还算不错，绝大部分都很流畅。我在三月份见到了译者乔梁，他和这本书的作者原来是ThoughtWorks的同事。09年在一起完成了某个项目完成之后，他的同事就写了这本书，而他可以说全程参与了这本书的诞生全过程。他后来在百度成功的对一支两百多人的团队进行了改造，把发布周期从三个月降低到了三周，而且还在继续缩短这个周期。我不知道按照这本书第十五章的表格，这支团队达到了怎样的级别。但据我所知，国内的大多数团队都还在-1级晃悠。

　　如果说软件开发的完整流程包括需求和系统分析、编码与测试以及发布三个阶段的话，这本书主要阐述的是最后的“发布”阶段。这本书不会告诉你怎样设计架构，也不会告诉你怎样编写测试，它要说明的问题是，软件的发布并不是一个轻松而简单的过程。DRY原则的实践不仅在于编码阶段，也适用于配置管理、版本控制等各个方面。

　　诚如这本书的译者序所说，它适合于软件项目组中的所有人，包括产品经理、技术经理、开发、测试、运维等等。但最重要的是，这本书适合的是那些勤于思考的人，那些看到问题并希望改善现状的人。

　　这本书系统的阐述了“部署流水线”这个概念、它的优势和它的各个部分的实现。部署流水线是一个综合的工程，它既涉及到需求分析（行为驱动与验收测试），也涉及到配置管理（版本控制与自动化部署），还涉及到了数据（数据库结构的版本、测试数据的生成和管理）等等。这本书介绍了许多成熟的工具，它们为读者所在的团队选择相应的工具提供了一个很好的起点和参考。这本书引用了许多好书和博文，都值得一看。

　　这本书应该是软件工程的经典教材，但又不可能是，因为在校的学生是看不懂的。

　　随手翻了一下其他看过的同学的评论，有人说这本书只在“特定的环境”下才有参考价值，有人说这本书的理论大于实际应用。我只想说这些人的项目经历都太单纯。如果你也有类似的感受，不妨再多写几年代码，多经历几次痛苦与绝望，再回来看这本书。

　　《持续交付》读后感(九)：补充笔记

　　code.flickr.com 《a pratical way to large scale agile dev》

　　minimum viable product 《The lean startup》

　　频繁发布的原因：

　　1. 发布用户需要的最小功能，快速反馈，容易满足用户需求；

　　2. 减少风险：增量小，容易发现问题。

　　宝马： MTBF 昂贵系统关注

　　吉普车：MTRS 推荐

　　原则：

　　创建可重复的发布过程；

　　自动化所有事情（除了一些手工探索测试）；

　　一切放入版本库；

　　如果它让你很痛苦，你需要做的更多做它；

　　W.Edwards Deming: 停止依赖大量的检查来得到质量，把提高过程和构建质量放在第一位。

　　每个人都对交付负责，不管是商业，开发，测试，运维人员。

　　持续改进：从内部自己持续思考如何改进，不是依靠外部教练。 戴明环： PDCA，每周总结。

　　部署流水线实践：

　　对不同的环境用相同的方法部署：UAT，性能测试环境；

　　对部署进行冒烟测试/验证；

　　保持各个环境统一：整个软件堆栈版本，一些环境无关配置；

　　测试：

　　金字塔： unit -> service -> UI 越来越昂贵，应逐步减少 《succeeding with agile》

　　验收测试应该按场景来分而不是story级别，每个验收测试有自己的隔离的测试数据，不要相互依赖，可以并行进行；

　　开发和测试人员一起写测试；

　　架构的时候考虑性能，可扩展，也要考虑是否好测试，是否好部署，是否好进行单元测试。

　　配置管理：

　　特性分支（不推荐，和持续集成有矛盾，重构了代码则对合并影响很大）；发布和试验分支是可以的。

　　facebook很多的使用特性开关。

　　康威法则：组织结构和通信结构相关。

　　AMAZONE从单个主干分解开，实现SOA：

　　1. SOA需要小团队，每个团队对应一个服务。

　　2. 团队是跨功能并持续为这个服务生命周期负责。

　　蓝绿部署： 两个版本，路由切换到新版本或回滚到旧版本。 DB也有2个，数据迁移是个问题。

　　金丝雀发布： 一部分服务器部署新版本，部分用户在新版本上，旧版本服务器逐步切换到新版本。 facebook

　　免疫系统： ？

　　黑发布： facebook 聊天服务 ？

　　特性开关： facebook gatekeeper 可以达到 服务降级（流量大的时候，IO,CPU占用高的服务关掉），或类似回滚的效果

　　紧急修复也要走以上所有流程。

　　数据库部署的升级回滚： still hard

　　dbdeploy.com

　　《recepies for continouse db integration》

　　《refactoring database》

　　零停机DB部署：

　　1. event soucing：

　　2. CQRS

　　3. nosql

　　运维：

　　devops: 双方更好的沟通

　　《release it! design and deploy product-ready software》

　　基础设施 = 环境+支持服务（网络，存储）

　　如果一台服务器扔出窗外，需要多久才能重建一台？

　　infrastructure as code : scm practices, refactoring, testing,deployment pipeline

　　DD cucumber-puppet: 测试 环境的变化，重构

　　监控：cucumber-nagios

　　管理，如果实施改进：

　　递增，迭代；

　　戴明环：PDCA

　　设置目标和衡量结果

　　《持续交付》读后感(十)：软件交付的最后一公里

　　本书围绕开发和运维之间的常常被忽视的部署上线环节来讨论开发过程和运维过程管理。是关于Devops的难得的实战总结。

　　部署流水线：

　　就是指一个应用程序从构建，部署，测试到发布这整个过程的自动化实现。这些环节在软件交付中常常被忽视，而又常常会导致了软件本身功能出现问题。

　　常见软件发布反模式，P4：

　　手工部署软件；开发完成后才向类生产环境部署；生产环境的手工配置管理。

　　软件交付的原则：

　　不但对应用程序进行测试，也要对部署过程进行测试。

　　为达到交付软件的短周期，高质量，我们需要频繁且自动化的发布软件。相当于多做练习。

　　基础架构的配置要像源代码一样被配置管理起来，infratructure as code。

　　开发人员每次代码提交都可能产生一个可发布的版本，即在一次提交后就开始检验集成版本，提交集成之前是本机单元测试。传统方法是推迟集成。

　　几乎所有事情都自动化，把所有东西都纳入版本控制。

　　我们的目标是尽快发现错误，并消灭他们，而不是期待完美和零错误。

　　非常高的单元测试覆盖率才有可能保证快速反馈，这也是持续集成的核心价值。

　　为什么二进制包应该具有环境无关性，P92。

　　自动化构建：

　　uildr建立在Rake至上。如果刚开始一个java项目，或想寻找Ant或Maven的替代品，我们强烈推荐Buildr。

　　使用同样的脚本向所有环境部署。不建议用ant,因为运维团队不知道ANT,会拒绝使用ANT来自动化部署。

　　我们可以从运维团队和开发人员一起把应用程序部署到某个测试环境的过程自动化开始。

　　库文件管理，一种全部放到配置管理库中，一种使用Maven或Ivy管理，这时就不需要将库文件提交到版本库中了。

　　二进制包和源码版本库的内建可追溯性：

　　1. JAR的manifest文件中元数据放入版本号；

　　2. 二进制包MD5值和版本号（svn revision）对应关系放在一个数据库中。

　　发布：

　　在一定的工作负载下，当每个单独请求的响应时间维持在可接受的范围内时，该系统所能承担的最大吞吐量被称为他的容量。性能常被用来指这些术语的集合。

　　部署与发布的区别主要在于回滚能力。

　　蓝绿部署：2个相同生产环境，互相可切换，通常是试运行环境先部署新版本，然后切换正式上线。

　　金丝雀发布：把某个版本部署到部分服务器，尽早发现问题，而不影响大多数用户，这时一个大大减少新版本发布风险的办法。容易回滚，方便做A/B测试，逐步增加负载，慢慢吧更多用户引到新版本。

　　极限编程座右铭：如果它令你很受伤，那么就多做练习。 （不是推迟或者少做而积累风险）

　　UNIX环境一个最佳实践是：把应用程序的每个版本部署在一个单独目录中，用一个符号链接指向当前版本。部署和回滚就是改一下符号链接。 网络服务可以把不同版本放在不同服务器上，或同一服务器用不同端口。

　　运维：

　　强调合作是DEVOPS的核心原则之一。DEVOPS运动的目标是将敏捷方法引入到系统管理和IT运营世界中。

　　系统环境问题调试的辅助工具：Wireshark，tcpdump, lsof. windows：handle,tcpview,sysinternals套件

　　It运维领域的杀手级工具:splunk，对数据中心所有日志和其他文本文件进行实时搜索。

　　程序默认应该记录WARNING,ERROR和FATAL级别日志。

　　数据库：

　　数据的模式版本和程序版本要对应。

　　数据库版本管理工具： dbdeploy, itbatis的dbmigrate

　　配置管理和组件化：

　　一个主干，好处：

　　1. 确保所有代码被持续集成；

　　2. 确保所有开发人员及时获得他人的修改；

　　3. 避免项目后期的“合并地狱”和“集成地狱”

　　一个主干，同时保持应用程序可发布的方法：

　　1. 将新功能隐藏，直到完成为止。比如对应功能在菜单上是否显示出来。可配置。

　　2. 所有变更都变成一系列增量式小修改，而且每次小修改都是可以发布的。

　　3. 抽象模拟分支：让修改地方创建一个抽象层，抽象层的当前实现是可以发布的。创建新的实现代码，在新的完成后切换到新的实现上，如果不需要抽象层了，就删除掉。抽象层的隔离接口比较不好找。

　　4. 组件化解偶。

　　Java的依赖地狱更加严重，最初设计使同一个JVM上每个类只能有一个版本生效。OSGI解决了这个限制。

　　组件化依赖管理，可以使用开源Artifactory和Nexus管理自己的制品库。可以将一个二进制文件关联到版本库中源代码版本上。

　　建议外部库文件名上加上版本号。

　　组件定义：可被实现相同API的其他代码所替换，可以独立部署（二进制）。

　　超过十人的团队建议组件化，但不建议一个团队负责一个组件，而是有能力开发端到端的跨功能团队更高效，即一个建议一个团队负责一个用户故事，每个团队都可以修改任何组件的代码。每个团队负责一个组件的严重风险是，整个应用通常到项目后期才能集成工作起来。

　　对依赖进行版本管理至关重要，持续集成工具要确保每个组件的版本是一致的，防止“依赖地狱”这样的事情。

　　一个可控的分支策略（可以说是业界标准）是：只为发布简历长周期分支。新功能被提交到主干上，在发布分支上修改问题然后发布，再合并到主干（建议定期如每周合并，避免最后合并，时间跨度大而难以合并）。