增量部署和全量部署

应用部署是工程人员（包括开发、测试和运维），每天需要面对的重要工作之一，尤其是交付比较频繁的项目，工程人员需要花费很多的时间和精力去完成越来越频繁的部署工作，那么部署的方式是选择增量部署还是全量部署呢？

增量部署

增量部署一般是指在部署的过程中提取提取当前版本和部署版本之间的增量文件，并且在部署的过程种仅更新增量部分。
这种部署方式在很多的项目中有着比较广泛的应用，使用这种部署方式的主要原因如下：

1. 部署速度快，增量部署每次仅对增量文件进行更新，无论是文件传输还是配置更新覆盖的内容都会比较少，部署的时间也会相应的缩短。
2. 减少生产环境的变化量，增量部署减少了生产环境的变化幅度，而且本次部署哪些内容发生变化可控，出现问题比较容易追踪，而且也不需要再对已配置过的文件重新进行设置，降低出错的概率。

全量部署

全量部署相对于增量部署，是对项目中全部文件进行更新部署，相对于增量部署，能够保证线上环境和发布版本的一致性，而且对于计划外的部署（为修改一个问题临时更改生产环境文件），具有很高的容错性。但是全量部署是更新系统全部文件，部署环境变化幅度大，文件的传输，部署速度会比较慢。

部署方式的选择

在选择部署方式之前，我们先来考虑一下对于一个部署操作来说，哪些指标是最为重要的，部署的可重复性，可预测性以及可回滚性是最为核心的考量，其次才是部署的效率和安全。
随着系统的持续集成，部署的情况越来越多，系统的部署存在以下特点：

1. 部署操作次数多，持续交付已经成为企业的普遍追求，也是IT服务能力的核心指标，当部署次数多起来，每次部署的可预测性以及可回滚性是最基础的保障。
2. 部署环境变化多，部署环境不仅仅局限于开发、测试、仿真以及生产环境，而且每个环境中部署频繁，这就对部署的可重复性提出很高的要求。
3. 部署操作人员多，随着自动化部署以及持续集成的普及，越来越多的人需要有执行部署操作的能力。这不仅包括传统的开发、测试和运维人员，还包括公司管理人员，甚至市场及销售人员都需要有自己快速部署一套系统（用于演示或者其他目的）的需求。这也要求部署操作有很好的可预测性和可重复性。

如果对照以上特点，增量部署很难满足全部的要求，具体原因如下：

1. 增量部署对于任何部署外的更新非常敏感，降低了部署流程的可预期性。在日常工作中经常会出现为修复一个问题而临时修改运行环境的部署外更新，一旦这些部署外更新未及时考虑到增量计算中，非常容易导致之后的增量部署失败。全量部署过程则会完整执行完整个环境的配置、初始化以及部署工作，对于这些部署外更新有更好的容错性。
2. 增量部署让回滚操作变得非常不容易。每次回滚都需要逆向计算增量部分，然后做回滚操作。及时的备份策略有机会降低这个难道，但是如果需要回滚多个版本仍然是一个巨大的挑战。
3. 增量部署无法直接满足从头部署最新系统的日常需求。在云环境中资源的动态变化（尤其是虚机的增加和减少）逐渐会成为一个常态，用户时刻都可能面对两种场景的部署要求：从上个版本升级到最新版本，或者从零重新部署最新版本应用。显然，这两种部署需求一个增量更新，另一个则是全量更新。

如上这些挑战都让增量部署模式越来越难满足高频部署的工程需求，越来越多的自动化部署系统及工具都选择了全量部署模式。当然，在选择全量部署模式时，前面提到的全量部署模式弊端也需要认真考虑。简单来说，我们可以通过下面这些策略解决或者缓解这些弊端：

• 提前在本地准备好全量部署所需要的所有材料（部署包、配置文件等）后再开始部署操作。这样可以让部署操作都变成本地操作，大大提升部署的效率和速度。
• 使用如灰度发布或者负载均衡等方法降低全量部署对于应用可用性影响。同时还能够有效解耦部署和发布两个阶段，提高应用发布的灵活性。

总结来说，对于现代系统中绝大部分状态无关的部署单元（应用、模块，微服务等），全量部署一般应是最优的选择，而对于像数据库这类与状态有关的系统，还是只能够使用增量部署，并且还要小心设计部署的流程、脚本及回滚策略