GitLab回滚前，别把旧部署记录当成完整的构建备份

在环境页面看到一次成功的旧部署，只能说明那里保存了部署历史，并不自动证明现在仍具备重新部署所需的全部文件。回滚准备应同时回答目标版本是什么、部署任务会做什么、它所依赖的产物在哪里。

GitLab部署文档说明，回滚到某次提交时会创建一次新的部署，这次部署有自己的任务ID，并指向要恢复的提交。回滚执行的是部署任务；如果先前任务生成的产物需要重新生成，必要的前置任务要从流水线页面另行运行。[1] 因而，不能把回滚理解为自动倒放整条旧流水线。

可先将一次回滚计划拆成三项关联：目标提交、对应的部署任务、部署脚本使用的产物或其他输入。这里的目标是弄清依赖关系，不是立即点击重跑。若部署依赖前面的构建结果，应检查那一份结果是否仍可获得；若部署前还有需要重新生成的输入，也应在计划中标出负责生成它的任务。

产物保留还受另外一套规则影响。GitLab的Job artifacts文档说明，expire_in控制产物保留时间，未设置时采用实例的默认到期设置；页面也说明了最近流水线相关产物的默认保留行为，以及项目可以关闭相应保留设置。[2] 因此，“上次部署成功”不是“旧产物永久存在”的同义词，具体可用性应以项目实际配置和产物记录为准。

本文建议在变更记录里为每项输入注明来源任务、关联提交、检查时间和是否已经核实可取。找不到的输入保持缺失状态，而不是用同名的新文件替代后继续把它称为旧版本。需要重跑任务时，也要明确其输出将供哪一次部署使用，避免把不同流水线的结果混合成无法追溯的组合。

最后，将部署历史、代码版本和业务数据恢复分开讨论。GitLab页面的上述回滚说明只解释部署任务机制，不能据此保证数据库变更或外部服务状态一并恢复。先把文件依赖和回滚边界写清，再按项目既有的变更流程验证，才便于判断这次回滚是否具备执行条件。