Azure DevOps 如何确保多个 Release 按创建顺序部署？

结论

在 Classic Release Pipeline 中，Deploy all in sequence 配合最大并行部署数 1，可以让同一阶段的 Release 依次部署。Microsoft 文档以 R1、R2 为例，说明队列中的 Release 会按该顺序处理。文档没有说明系统会按 Release 创建时间重新排序。若必须保证最旧的 Release 先部署，还需要控制它们进入部署队列的顺序。

先检查队列中的实际顺序

Deploy all in sequence 会等待当前部署及其后置审批完成，再处理下一个 Release。文档示例中的顺序是 R1、R2。这个设置会限制并发、依次处理队列，但没有承诺按创建时间或 Release 编号排序。Microsoft：Specify queuing policies

先在 Releases 页面核对 R1、R2 的创建时间和 Release 编号，以及目标阶段的部署状态、部署时间和预部署、后置审批的完成时间。还要确认顺序反转发生在同一条 Release Pipeline 的同一个阶段，而不是由其他阶段或触发源先启动了部署。

需要严格顺序时的处理方式

如果业务要求从旧到新部署，可以由调度流程明确控制顺序：按 Release 编号或你们定义的版本顺序选出待部署项，先启动最旧的 Release，等目标阶段部署完成后再启动下一个。也可以通过人工审批逐个放行，前一个 Release 完成后再放行下一个。Microsoft 对需要手动控制执行顺序的 YAML Pipeline 也建议使用人工审批；YAML Pipeline 本身不支持这些队列策略。Microsoft：Specify queuing policies

继续使用 Classic Release Pipeline 时，可以保留 Deploy all in sequence 和最大并行数 1，同时确保调度流程按预期顺序创建或触发 Release，并检查运行记录。如果队列中 R1 明明先于 R2，实际却是 R2 先部署，现有描述无法判断具体原因。可以记录 Release ID、创建时间、阶段状态和部署时间，再据此排查或向 Azure DevOps 支持反馈。

注意事项

先创建的 Release 不一定会由服务端先部署。串行化只能控制部署并发，部署顺序仍应由上游调度或逐个审批明确安排。

备注：内容仅供参考。