确保部署流程是幂等的（Idempotent）

无论开始部署时目标环境处于何种状态，部署流程应该总是令目标环境达到同样（正确）的状态，并以之为结束点。

做到这一点的最简单方法就是，将已知状态良好的基线环境作为起点，要么是通过自动化，要么是通过虚拟化方式准备好的。这里所说的环境包括所有需要用到的中间件

，以及让应用程序能正常工作的任何软硬件。然后，部署流程可以获取指定的应用程序版本，并使用（对于中间件来说）适当的部署工具将其部署到该环境中。

如果你的配置管理做的不够好，还无法满足这一要求的话，下一步最好把部署流程对该环境作出的那些前提假设验一遍。如果这些假设不成立，就让部署失败。比如你要验证一下适当的中间件是否已经安装了，是否正在运行，是否为正确的版本。而且，无论如何，你都要验证一下该应用程序所依赖的外部服务是否也在运行并且为正确的版本。

如果应用程序通过了测试、构建，并已集成为一个整体的话，通常应该以部署单件的方式来部署它。也就是说，每次部署时都应该基于根据版本库中的某个单一修正版本生成的二进制包从头开始。对多层系统也是一样，比如同时开发了应用程序的表现层和应用层。那么当部署其中的某层组件时，就应该将任意一层上的组件都部署一次。

为了将变更最小化，很多组织坚持只部署那些发生过修改的组件。然而，我们很难回答“哪些东西发生了变更”这个问题，而且这一判断过程比从头开始部署更容易出错，也很难测试。当然，所有可能的变更组合是不可能的，所以如果某个没有想到的无法控制的情况恰恰在发布时发生了，就会使应用程序处于某种未知状态。

对于这一原则，也有一些例外情况。首先，对于集群系统来说，总是将整个集群系统同时重新部署就不可取。

其次，如果应用程序是由多个组件构成的，而这些组件来源于不同的源代码库，那么二进制包就由这些源代码库中的一系列修正版本（x、y、z.....）来定义。此时，如果你知道仅有一个组件发生了变更，而且将要部署到生产环境的所有组件的组合都已经测试通过了的话，那么只部署这个发生变更的组价就行了。这里的关键区别在于从上一个状态更新到新状态的过程已被测试过。这一原则也适用于面向服务架构的服务部署上。

最后，还有一种方法，那就是使用效果幂等的工具进行部署。比如，无论目标目录中的文件处于什么状态，Rsync都会使用一种强大的算法，仅通过网络传输目标目录与源目录中不同的部分，确保某系统上的目标目录与另一个系统中的源目录是完全一样的。版本控制的目录更新也能达到相似的结果。