持续交付 - 第一章(未完)

受如何阅读一本书的影响，我首先看了这本书的前言和目录部分，了解到这本书的大致结构，主要分为三部分，每部分的耦合性较低，方便读者将其用作工具。

第一部分：基础篇。从第一章到第四章，讲述有规律，可重复，低风险发布的基本原则和与其相关实践。
第二部分：部署流水线。从第五章到第十章。
第三部分：交付生态圈。从第十一章到结束。深入分析了支撑持续交付的生态系统。

接下来谈谈我在阅读前言和第一章过程中的收获：

• 对团队开发而言，持续交付的基础是持续集成（CI）。CI使整个开发团队保持同步，消除了集成问题引起的延期。

一些常见的发布反模式：

1.手工部署软件：

存在的问题：

• 每个步骤里都会有一些人为判断的事情，因此很容易发生认为错误；
• 手工部署流程文档维护复杂且费事；
• 手工部署过分依赖于专家；
• 手工部署测试过程成本高昂。

建议：

• 部署应该走向自动化。

2.开发完成后才像类生产环境部署：

存在的问题：

• 运维人员，真正执行部署任务人员等可能是第一次接触这个产品，在这种方式下执行部署过程中，会发现系统设计中存在对生产环境的错误假设。

建议：将测试，部署和发布活动也纳入到开发过程中。

3.生产环境的手工配置管理：

存在的问题：

• 多次部署到试运行环境都很成功，但当部署到生产环境时就会失败；
• 集群中个节点的行为有所不同，所以导致它们负载不同，或处理请求的时间也不同等；
• 维修团队需要较长时间为每次发布做准备；
• 系统无法回滚到之前部署的某个配置。

建议：

• 对于集成测试环境，试运行环境和生产环境的所有方面，尤其是系统中的任何第三方元素的配置，都应该通过一个自动化的过程进行版本控制。

疑问：

• 自动化这个词，贯穿了整本书，但自动化具体是怎么做到的？是用了哪些工具？