持续交付-发布可靠软件的系统方法
本书主要内容在于持续集成和持续交付部分，个人认为可以用于持续集成和持续交付的基础教学。
一、基础篇
1.1 软件交付问题
1.1.1 奇奇怪怪的发布模式
- 手工部署软件
- 开发完后才向类生产环境部署
- 通过运维团队来管理生产环境的配置
手工部署软件的缺点：成本代价高，部署环境未自动化，每次部署时会发生错误且追查难，手工部署需要文档支持而文档维护成本高
在一个产品发布过程中，需要将测试、部署和发布活动也纳入开发过程中，让它们成为开发流程的一部分。
通过运维团队来管理生产环境，需要由团队登录到生产服务器进行手工修改并记录，系统无法回滚到之前部署的某个配置，包括操作系统、应用服务器、关系型数据库等
总结：
自动化部署能够省去很多麻烦，其带来的便利性也是显而易见的，同时在一个产品发布过程中，需要将测试、部署和发布活动也纳入开发过程中，让它们成为开发流程的一部分
1.1.2 软件交付的原则
软件部署三件事：
- 提供并管理必要的环境
- 将应用正确版本安装在正确环境上
- 配置应用程序，包括其所要的任何数据以及状态
软件交付的原则：
- 为软件发布创建一个可重复且可靠的过程
- 将测试等所有事情自动化
- 把所有东西纳入版本控制
- 提前并频繁地做让你感到痛苦的事（指优先解决项目中最痛苦的事）
- 越早发现错误，修复成本越小
- 交付团队的每个人都应该对应用程序的质量负责
- 戴明环原则：Plan - Do - Check - Action（PDCA原则），每个改进点都应该有一个人负责跟踪
1.1.3 如何实现目标
敏捷测试的基础在于速度，各环节的速度是至关重要的。除此之外，在保障速度的同时，还应该保障质量，速度虽然重要，质量才是基础。
在找到一种高效、快速、可靠的高质量且有价值的交付软件的方法过程中，我们容易发现，对于软件整个流程，我们需要频繁的修改和发布软件，原因如下：
1. 自动化。如果构建、部署、测试和发布流程不是自动化的，那它就是不可重复的。由于软件本身、系统配置、环境以及发布过程的不同，每次做完这些活动以后，其结果可能都会有所不同。由于每个步骤都是手工操作，所以出错的机会很大，而且无法确切地知道具体都做了什么。这意味着整个发布过程无法得到应有的控制来确保高质量。常常说软件发布像是一种艺术，但事实上，它应该是一种工程学科。
2. 多发布多保存。如果能够做到频繁发布，每个发布版本之间的差异会很小。这会大大减少与发布相关的风险，且更容易回滚。频繁发布也会加快反馈速度，而客户也需要它。
除此之外，本书还说到，对于整个流程，每一个步骤都需要尽快接收到反馈，并且交付团队必须接收反馈并作出反应，原因如下：
参与软件交付过程的所有人（包括开发人员、测试人员和运维人员、数据库管理员、基础设施的专家以及管理者）都应该参与到这个反馈流程中，这是至关重要的。如果这些人无法做到每天都在一起工作（尽管我们认为团队应该是全功能团队），就一定要常常碰头并一起探讨如何改进软件交付的流程。对于快速交付高质量的软件来说，基于持续改进的过程是非常关键的。迭代过程有助于为这类活动建立规律性，例如每个迭代至少开一次回顾会议，在会上每个人都应参与讨论如何在下一个迭代中改进交付过程。
这里其实还提到，软件发布其实是一项工程学，对于这部分个人思考，确实如此。整个软件可以看做是一辆车，车简单来说包括车身、身门、车轮、发动机以及各种配件，可以对应软件发布的各个功能模块。
对于每个功能模块里的函数，首先要完成单元测试，确保模块没有太大问题，并由软件开发人员编写单元脚本进行后续维护。（开发人员确保）
完成以后，配件组成对应功能模块，这里应该由自动化测试人员确保功能的正确，由测试人员编写自动化测试用例和自动化测试脚本来完成流水线维护。（后端接口测试以及功能测试人员确保）
在各功能模块都没有问题后，就可以组装成软件了，这里涉及到前后端联调，由前后端测试人员一同完成测试，并由前端测试人员完成后续系统测试。（前后端测试人员确保）
在完成后，还需要将整个软件，交付到测试流水线上进行运行。测试流水线包括开发人员的单元测试、后端测试人员的自动化测试、前端人员的UI测试等测试脚本，还包括新增的功能测试脚本。
个人理解，在完成以上操作后，后续的软件开发其实就比较快了，只需要完成新增功能的测试就可以做到部署流水线了。
1.1.4 持续部署 、持续集成的收效
1、 可选择性。使测试人员、运维人员或支持服务人员能够做到自服务，即他们可以自行决定将哪个版本的应用程序部署到哪个环境中，缩短软件发布周期的时间。
测试人员可以选择性部署旧版本以验证新版本的功能变化；
技术支持人员可以自己部署某个已发布的版本，用于重现缺陷；
可以作为灾难恢复手段，由运维人员在发现重大缺陷时及时部署某个已知的无问题版本进行减少灾难。
发布也成为一键式的了。
2、 缓解压力。绝大多数经历过项目发布的人都会认为，当项目越临近发布日期，就越能感觉到压力。根据我们的经验，压力本身就是问题的根源所在。现在，让我们来设想一下。如果接下来的发布只需要单击一下按钮，而且只需要等上几分钟，甚至几秒钟内就可以完成。另外，假如发生了非常糟糕的事情，你只要花上相同的几分钟或几秒钟的时间就可以把刚部署的内容恢复到从前的老样子。再大胆地设想一下，假如你的软件发布周期总是很短，那么当前生产环境中的版本与新版本之间的差异应该非常小。如果上述设想都是事实的话，那么发布的风险一定会大大降低，那种将职业生涯压注在发布是否成功的不爽感觉也将大大减少
3、 灵活部署。在一个全新环境上运行应用程序应该是相当简单的事。理想情况下，只要安装机器或虚拟镜像，然后配置一些与具体运行环境相关的特定选项。然后，你就可以使用自动化过程准备好新的部署环境，并选择指定的应用程序版本进行部署。
