部署流水线权限管理：谁该能改生产环境？

小王刚接手公司 CI/CD 流水线，第二天就收到运维同事的微信：‘你咋把 prod 分支自动发布关了？’——他只是想测试下 Jenkins 权限配置，顺手点了下‘禁用构建’，结果整个线上更新卡住了。

权限不是越严越好，而是要分得清、控得住

部署流水线不是‘谁有账号谁就能点’的地方。一个没加限制的‘Deploy to Prod’按钮，可能比一个没设密码的数据库更危险。常见角色其实就三类：开发者（能提交、触发测试流水线）、测试人员（能查看报告、重试测试任务）、运维/发布负责人（唯二能审批或执行生产部署的人）。

GitLab CI 和 Jenkins 的实操区别

GitLab 默认按项目成员角色控制 pipeline 触发权限，但不能靠默认吃老本。比如，即使你是 Maintainer，也可以在 .gitlab-ci.yml 里加个保护规则：

deploy-prod:
  stage: deploy
  script: ./deploy.sh prod
  rules:
    - if: $CI_COMMIT_TAG
      when: never
    - if: $CI_MERGE_REQUEST_SOURCE_BRANCH_NAME == "main" && $CI_PIPELINE_SOURCE == "merge_request_event"
      when: never
    - if: $CI_COMMIT_BRANCH == "prod" && $CI_PIPELINE_SOURCE == "push"
      when: manual
      allow_failure: false

这样，只有手动点击 + prod 分支 push 才能触发，且必须由有 maintainer 或 owner 权限的人操作。

Jenkins 则更依赖插件，比如安装 Role-based Authorization Strategy 后，可以建三个角色组：dev-runner（允许构建 dev/test job）、qa-viewer（只读所有 build 日志）、prod-deployer（仅能 Build/Promote prod-deploy job）。再把对应人加进组，比一堆勾选框清爽得多。

别忘了“环境级”隔离

同一个 Jenkins 实例里，test-env 和 prod-env 的凭证绝不能混用。建议用 Jenkins Credentials Binding 插件配合 Folder-based 权限：把 prod 相关 job 全放进 /prod-pipeline 文件夹，然后单独给这个文件夹设置 prod-deployer 组的 Job/Build 权限，其他组连 job 列表都看不到。

最后提醒一句：权限调整后，一定自己换个小号登录试一遍。真有人反馈‘点不动’，先别急着查日志——大概率是刚删掉他所在的权限组。