1.3　DevOps视角

一个重大的呼吁是缩短新功能推向市场的时间，减少部署过程中发生的错误，考虑到我们讨论的问题并且这些问题都存在已久，这种呼吁也就不足为奇了。DevOps有很多形式，是对现有实践不同程度的改编，但是各种不同形式都始终贯穿着两个主题：自动化及开发团队的职责。

1.3.1　自动化

图1-1显示了各种生命周期过程。从构建、测试到执行的步骤在某种程度上都可以实现自动化。我们将在适当的章节中讨论这些步骤中的每一步使用的工具，这里首先强调自动化的优点。在1.7节中讨论依赖于自动化的一些问题。

工具可以执行这个过程中每一步所需的操作，针对生产环境或者一些外部规格说明检查操作的有效性，把过程中发生的错误通知适当的人，并且保留操作历史，以用于质量控制、报告和审计等目的。

工具和脚本也可以强制推行组织层面的策略。假设组织有一项策略是，每个变更都要有与之相关的合理理由。那么在提交变更前，工具或脚本可以要求做变更的人提供理由。当然这个要求也可能被设法规避，但是让工具要求一个理由，将会增加对这个策略的符合度。

在工具成为一组过程的中心后，就必须对这些工具的使用进行管理。比如说，工具可以从脚本、配置变更或运维的终端调用。如果是复杂的终端命令，即使使用的只是几个命令，也建议把命令的使用脚本化。工具可以通过规格说明文件进行控制，例如Chef cookbooks或Amazon CloudFormation——今后还会有更多。脚本、配置文件和规格说明文件必须遵从与应用程序代码本身一样的质量控制。脚本和文件也应该进行版本控制，也应该进行错误检查。这个术语常常称为“基础设施即代码”（infrastructure-as-code）。

1.3.2　开发团队的职责

自动化将减少错误的发生，缩短部署时间。为了进一步缩短部署时间，考虑前面详细描述的运维人员的职责。如果开发团队接受DevOps的职责，即开发团队交付、支持并维护服务，那么因为所有所需的知识都保留在开发团队，所以向运维团队和支持人员转交知识也就少了。不需要转移知识也就省掉了部署过程中的大量协作步骤。