你以为并发控制只能靠 Redis 锁？今天 GitHub 把这件事用一行配置彻底原生化了

配了三年 CI，今天才发现团队里最常见的”灵异事件”不是代码 bug，是这个：新代码 push 上去，workflow 刚跑起来，又来了一个 commit，第二个 workflow 把第一个 cancel 了，第三个再 push 再 cancel——最后部署的那个人背着所有人的心理负担，不知道自己的改动到底有没有跑完。

这个问题在 2026 年 5 月之前基本无解。GitHub Actions 的 concurrency groups 只能容得下「1 个在跑 + 1 个在等」，第三个进来直接踢掉第二个。团队里开始各显神通：有人写 Redis 分布式锁，有人写外部脚本做重试，有人干脆把 workflow 改成只跑一半的测试——明明是 CI 配置问题，最后搞成了分布式系统难题。

2026 年 5 月 7 号，GitHub 给 concurrency groups 装上了一个真正的队列，最长能排 100 个任务。

核心就改一行配置

concurrency:
  group: deploy-prod
  cancel-in-progress: false
  queue: max

queue: max 一加，concurrency group 从「1 running + 1 pending」直接变成「1 running + 最多 100 queued」。谁 push 谁进队，按顺序跑，不 cancel 任何人。

之前靠 Redis 锁、数据库 lease 或者外部脚本才能实现的排队部署，现在三行 YAML，平台层面原生处理。

以前怎么 workaround 的

在 queue: max 出来之前，如果你想让部署按顺序排队，标准做法是自建锁机制：

# 用 Redis 做分布式锁
- name: Acquire deployment lock
  run: |
    while ! redis-cli set lock:deploy:$ENV ex 3600 nx; do
      sleep 10
    done

这套方案有几个问题：Redis 要花钱、锁 TTL 要算、释放逻辑要写、CI 网络不通 Redis 还要做降级——一个业务逻辑，配了 40 行胶水代码。

现在只需要三行 YAML。

实测效果

GitHub 官方公告（2026-05-07）之后，Concurrency groups 正式支持排队：

生产场景里，main 分支多个 PR 合并顺序不确定，以前靠人来协调，现在 push 顺序就是部署顺序，平台保证。

三步迁移

第一步：加 queue: max

concurrency:
  group: deploy-${{ github.ref }}
  cancel-in-progress: false
  queue: max

第二步：删掉 Redis 锁相关的 step

第三步：通知团队不用盯着 workflow 状态了。谁 push 谁在队列里等着就行，不会被 cancel 掉。

配了三年 CI，今天才发现「平台自带的功能比你自己写的锁更靠谱」这件事，GitHub 用 5 月的一行配置彻底证明了。