6.2　部署的自动化

要推进部署的自动化，就要解决这样一个问题：最初应该由谁着手实施？如何实施？其实答案就是“由想实施部署自动化的人着手去做就行了”。虽然有些简单粗暴，但这是最合理的解答。如果可能的话，最好以对服务器及网络相关事情有决定权的运维团队人员作为核心成员。因为不可避免地要预先做好环境相关的准备及调整，以及最终向正式环境实施自动化部署所需的准备工作。因此由运维团队的人员来牵头着手部署自动化，项目的进展会比较顺利。

6.2.1　部署自动化方面的共识

支撑部署自动化的技术方面，要选用开发人员（Dev）和运维人员（Ops）都能够使用的技术。关于这一点，在充分协商的基础上，双方达成一致是非常重要的。缺少任何一方的协助，都无法顺利实现部署的自动化。因为部署是指从开发到向正式环境发布应用程序为止的一连串行为。

要实现部署的自动化，需要全体团队成员就下面列举的 4 个项目达成统一认识。

❶ 要全部采用版本管理

❷ 所有的环境都要用同样的方式来构建

❸ 要实现发布工作的自动化，并事先进行验证

❹ 要反复多次进行测试

❶ 的话请参考第 3 章的版本管理系统。不仅仅是应用程序的代码，自动化相关的工具、数据库、测试用的数据等都应该作为版本管理的对象。这么做是为了在任何时候都能够恢复到过去的任意状态。

关于 ❷ 和 ❸，我们要意识到应该采用相同的方法来构筑开发环境、测试环境、正式环境并实施发布。这是在推进使用工具进行环境构建的过程中必须努力做到的要点之一。即便是手动修改了 1 行配置，那么从这一刻起这个环境中就混入了只有实施修改者才知道的信息。

❹ 是指对自动化部署实施持续的验证，大量收集其成功和失败的信息。只有这样，向正式环境实施部署工作的准确性才能得到保证。如果能够做到上述全部内容，那么部署将不再是可怕的事情。

6.2.2　部署流水线

实现应用程序的 build、部署、测试、发布这一系列流程的自动化称为部署流水线（deployment pipeline）2 （图 6.1）。

2 详细内容请参考之前提到的《持续交付》。

图 6.1　部署流水线

●…… 通过自动化加快部署速度

我们的目标是构建这样的部署流水线，并通过流水线的循环尽量加快部署的速度，同时还必须确保正确性。能够想到的最差情况就是：从着手开发到发布经历了数月 ～ 数年之久，并且全部采用手工作业，还出了差错。因此，在部署流水线的每一个阶段都需要全体团队成员就之前提到的部署自动化中的 4 个项目达成统一认识。

部署流水线的每个阶段都有着各种可以使用的工具。将各个阶段的工具组合起来就有可能加快部署的速度。

例如，提交某个 bug 的修改，由提交引发持续集成的运行，顺利通过 build 后自动部署到测试环境，执行用户验收测试，通过测试的话向正式环境实施部署，在正式环境上实施完冒烟测试 3 后向相关人员发送通知。到此为止的所有流程全部以自动化的形式实施。上述流程虽说是比较极端的例子，但确实是一种理想形式。

3 修改代码进行 build 时，为了确认 build 是否正常结束而进行的测试。

●…… 任何人都能够实施部署是很重要的

实际上一般的流程是当提交积累到一定数量时创建分支，并向正式环境实施部署。这里的重点是部署流水线要能够顺畅地运转起来，在部署的各个阶段都不允许有因为对人的依赖而无法部署的情况。理想的情况是任何人都可以实施测试，也都可以实施发布。

当然考虑到访问权限和审批流程的问题，最后按下发布按键的可能是特定的人，但并不是说这需要什么特别的技术。换而言之就是：不需要“发布技师”这样的人。

6.2.3　服务提供工具链（provisioning tool chain）

再稍微详细地对图 6.1 中给出的工具链进行一下说明。大致可以分为以下 3 个层次来考虑（图 6.2）。

图 6.2　服务提供工具链

• 引导（Bootstrapping）… 服务器 OS 的配置及基于虚拟机的服务器安装自动化的相关工具

• 配置（Configuration）… 服务器及中间件的配置自动化工具

• 业务流程（Orchestration）… 代码部署及发布相关的服务器操作等自动化工具

以上 3 个层次都无法只借助 1 个工具完成所有处理，只有集齐各个层次的工具并实现流水作业，部署流水线才能够完成。

接着我们来介绍几款在各层次中出现的工具。