文档中心
> 容器服务
容器服务
发布中回滚
通常，为了系统的稳定性，系统发布我们都会做金丝雀发布或者分批发布。在系统发布过程中，如果观察金丝雀发现存在问题，则我们需要即刻回滚，减少对用户的影响，这时我们就需要“发布中回滚”功能。
例子：
比如正式环境有2个应用实例，发布过程中，由于代码问题导致1个应用实例异常下线，此时状态变成：1 个正常，1个异常；发布中回滚，会将异常的实例恢复到之前正常的情况，而原本就正常的应用实例则不会进行任何操作，不会造成服务不在线
发布中回滚的机制
简单来说，发布中回滚就是：将当前环境回滚到这个环境最近一次的发布成功的发布单所对应的状态（扩缩容的发布单除外，因为扩缩容不会造成配置或代码的变更），部署配置以及代码包都和最近一次的发布成功的发布单一致。
限制（一定要满足，否则回滚达不到预期）
- 由于发布中回滚依赖之前的部署配置和代码包，因此需要确保历史的部署配置和历史代码包能够被访问
- 部署配置方面：
- 如果是官方镜像，官方镜像会自动保留，不需要用户做什么；
- 如果是自定义镜像，请确保你的历史镜像版本保留；
- 代码包方面：
- 如果你是在聚石塔paas平台上上传代码包的方式发布，则平台默认会留存代码包历史（留存三个月）；
- 如果你是将代码包集成到自定义镜像中的方式，请确保你的历史镜像版本保留即可；
- 如果代码包是通过挂载的方式在容器内访问，则无法回滚至历史的版本，因为聚石塔无法留存这种方式的代码包
- 如果代码包是自己的下载地址，请确保每次的下载url不同且保证历史的下载地址可以继续访问；否则，如果每次代码包都是覆盖之前的代码包，或历史的代码包清理了，那也无法回滚
例子：
a) 在发布单25527分批发布过程中，第一批发布完成后，我们发现了问题并且需要回滚，因此点击发布单中的“回滚”按钮；
b) 这时候产生了25530的回滚发布单，如回滚单上描述，系统回滚到了之前的发布单25515当时所对应的状态。为什么不是最近的25520发布单呢？因为25520发布单属于扩缩容，而扩缩容不会造成配置或代码的变更。
