并发控制是什么
对同一环境的操作加互斥锁：同一时刻只允许一个流水线或作业操作该环境，避免两个版本同时部署相互覆盖。与「自动取消冗余运行」是两种不同策略：互斥是排队，后到者等待；取消是打断，旧运行被终止。选哪种取决于该环境上「旧操作是否必须完成」，部署类操作通常必须完成后才允许下一个。
基本信息
| GitLab | resource_group 同名作业串行执行，常用于部署作业 |
|---|---|
| GitHub | concurrency 分组加 cancel-in-progress 设置 |
| 典型键名 | production、staging、deploy-环境名 |
| 语义区分 | 互斥是排队等待；cancel-in-progress 是打断旧运行 |
| 粒度 | 按实际互斥范围命名，避免所有环境共用一个组 |
GitLab
GitLab
deploy-prod:
stage: deploy
resource_group: production
script: ./ci/deploy.sh prodGitHub
GitHub
concurrency:
group: production
cancel-in-progress: false典型使用场景
- 生产部署串行：多个合并请求的部署依次排队执行。
- 共享环境互斥：测试环境被多分支共用时保证独占。
- 数据库迁移锁：同一库的结构变更脚本串行执行。
- 发布窗口：指定时段内仅允许一条发布流水线。
- 资源排他：部署会重启共享服务，必须单个执行。
两种策略对照
| 策略 | 行为 | 适用 |
|---|---|---|
| 互斥排队 | 后来者等待前一个完成 | 部署必须完整执行 |
| 取消旧运行 | 新运行打断旧运行 | 只关心最新提交结果 |
| 组合使用 | 组内互斥加可中断作业取消 | 常见的生产配置 |
并发组按环境粒度过粗会拖慢无关发布，按实际互斥范围命名。
GitHub 的并发组按仓库计算，同名即可互斥；分支场景使用同一组名时注意作用范围是否如预期。
部署类作业不要开启取消：被中断的部署可能留下半完成环境，需要人工核对后收尾。