简介

精彩点评

• 

  钱敏健

  推荐

  比较体系化，实战细节的一本持续交付的书，很多章节实际上可以选择性独立阅读。

• 

  安

  推荐

  这本书看的我又爱又恨，一方面是它确实介绍了不少部署流水线的知识，另一方面是你会发现他反反复复那几句车轱辘话，而且文章脉络不清晰。身为一个初学者，在做读书笔记的时候反反复复地删减和腾挪各个知识点，才总算画出了个大概。不知道是否是翻译地原因，文章里口水话不少，有些啰嗦。

• 

  爱学习的小马老师

  推荐

  本书针对于持续交付进行了宏观和具体的介绍，文中有例子和提问思考，很符合实际，能和作者引起共鸣。 这样的书后面会再来读，相信会有不一样的感受。 行了接下来就是去实践了，如下配置服务器再加上作者的方法，效率高到起飞。 戴尔r720xd ： E5-2660V2*2个 / DDR3 64G内存/ 三星 1tb固态*1个/H710/750w双电 价格：3600

• 

  陈良龙

  推荐

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

• 

  队长给我球

  推荐

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