研发负责人做 DevOps 选型，常被问三个问题：我们到底缺什么------是缺一个 CI 工具，还是缺整条交付链路？Demo 里都能跑通，为什么上线后还是要人工对版本、对发布记录？预算已经花在 GitLab、Jenkins、制品库上，交付为什么还是慢？
这三个问题指向同一件事：DevOps 软件选型，先分清「能力缺哪一段」，再谈「买哪家的产品」。托管、流水线、制品、发布、运维自动化，是交付链路上的不同环节，不是一张越买越长的工具清单。一体化平台和 GitLab + Jenkins 组合，解决的也不是同一个问题。
下文按交付链路分五类，梳理主流 CI/CD 与自动化运维方案各自适合什么，并说明两条集成路线怎么选------帮你在 PoC 和立项前，把候选从「听过很多名字」收窄到「真正相关的两三个」。
一、先按交付链路分五类
动手选型前，先对照自己缺哪一段：
| 类别 | 解决什么 | 常见代表 |
|---|---|---|
| 一体化 DevOps 平台 | 代码、CI/CD、制品、发布等同平台 | GitFox、GitLab、Azure DevOps |
| 代码托管 | 仓库、分支权限、MR/PR 评审 | GitHub、Bitbucket 等（单点工具） |
| CI/CD 流水线 | 构建、测试、部署自动化 | Jenkins、GitHub Actions、CircleCI |
| 制品管理 | 构建产物归档、版本回溯 | Nexus、Harbor；部分平台内置 |
| 自动化运维 | 配置、基础设施、监控告警 | Ansible、Terraform、Prometheus + Grafana |
二、主流方案各自适合什么
下面按第一节的五类能力简述。同一产品若已在一体化平台里覆盖多段能力，不必在后续类别里重复选型。
一体化平台（覆盖托管、CI/CD、制品、发布）
GitFox：禅道软件自研的一体化 DevOps 引擎，覆盖代码托管、CI/CD、制品库与发布，并与禅道需求、任务、Bug 原生关联。适合希望需求---代码---流水线可追溯、且有私有化或信创要求的团队。若团队不用禅道、也没有统一项目数据源的需求，应与其他一体化方案一并评估，而非默认替换。
GitLab：代码托管与内置 CI/CD 同平台，支持自托管和 SaaS，适合要私有化仓库、又希望流水线跟仓库在一起管的团队。不太适合的场景是：CI 需求极特殊、重度依赖 Jenkins 插件生态，且没有迁移意愿。
Azure DevOps：微软套件，含 Pipelines、Artifacts 等，适合 Azure/.NET 技术栈较重的组织。
代码托管（单点工具，常需另配 CI 与制品）
GitHub ：以仓库和 MR/PR 评审为主，本身不等同于完整 DevOps 平台。代码在 GitHub、且可接受云端托管时，CI/CD 通常用 GitHub Actions 补位；制品可用 GitHub Packages 或另配 Nexus/Harbor。
Bitbucket：常见于 Atlassian 栈，与 Jira 搭配较多。托管能力完整，CI/CD 需看是否启用 Bitbucket Pipelines，或外接 Jenkins 等执行层。
CI/CD 流水线（可单独补位，不替代代码托管）
Jenkins ：老牌开源 CI 引擎，插件生态强，流水线可深度定制。适合已有代码托管和制品能力、只需要灵活执行层的团队，以及历史流水线资产较多、短期不宜整体迁移的场景。不太适合：没有专职维护人力、却希望「装好就能用」的小团队。
GitHub Actions：与 GitHub 仓库原生集成，事件驱动触发。若第一节对照后确认「缺的是 CI/CD 这一环」，且代码已在 GitHub，Actions 往往是默认补位选项。
CircleCI：云端执行、配置相对轻，适合中小团队快速起步、不想自建 Runner 的场景；代码托管可在 GitHub、GitLab 或其他平台。
### 制品与自动化运维
Nexus / Harbor：独立制品库，常出现在 GitLab + Jenkins 组合里，负责镜像和包版本管理。
Ansible / Terraform ：前者偏配置与批量部署，后者偏基础设施即代码；解决的是环境与应用发布问题，不替代 CI/CD，但常与流水线串联。很多团队的误区是 CI/CD 刚搭好就急着上全套监控和 IaC------交付链路还没稳，运维自动化先缓一步往往更务实。
Prometheus + Grafana：运行期指标与告警，属于可观测性建设，与「能不能自动构建部署」是不同层次。标题里的「自动化运维」主要指这一类：它们让发布后的系统可观测、可告警，但不等于 DevOps 平台的替代品。
三、两条集成路线怎么选
| 关注点 | 一体化平台 | 多工具组合（如 GitLab + Jenkins + 制品库） |
|---|---|---|
| 部署维护 | 一套系统 | 多套系统分别维护 |
| 数据贯通 | 平台内原生关联 | 靠接口、Webhook 或脚本对接 |
| 灵活性 | 流程相对统一 | 各环节可单独替换、定制 |
| 更常见场景 | 从零搭建、强调追溯与合规 | 已有工具栈，只换其中一环 |
没有绝对优劣。工具栈已经成型、Jenkins 流水线投入很深，硬切一体化往往不划算；多个系统各管一段、人肉对版本号，则值得评估一体化或至少把制品、需求关联补齐。
下面三个问题，可以帮助快速筛掉一半不相关的名字：
- 代码放在哪？ GitHub 且可上云，Actions 往往是默认选项；必须内网自建，就看 GitLab、GitFox 等可私有化方案。
- 缺的是执行层还是整条链路？ 只有仓库、缺构建部署，Jenkins 或平台内置 CI 都能补；需求对不上代码和发布，问题在贯通，不是再多一个 CI 工具。
- 有没有合规硬约束？ 等保、信创、数据不出境会把 SaaS 和境外托管方案直接排除，候选范围会明显收窄。
四、按规模与形态圈定候选
以上只是方向，落到团队还要再看规模和部署形态。
10--50 人 ：已有 GitHub 可先用 Actions；自建 GitLab 则内置 CI 往往够用；只有仓库、缺流水线，Jenkins 仍是常见补位。不必一上来搭全套平台，先跑通「提交---构建---部署」再扩展。
50--300 人：流程规范和需求追溯变得重要，自托管 GitLab 或一体化平台（如 GitFox）更容易把需求、代码、发布串起来。此阶段要重点验收：MR 评审是否强制、制品能否回滚、权限是否按库/按环境细分。
300 人以上 / 政企金融：私有化、多级权限、审计留痕往往比「功能多」优先。等保、数据安全法下的日志留存、权限审批，应在 PoC 阶段就写进验收项，而不是立项后再补。候选范围会明显收窄，PoC 要验全链路而不只看 Demo 界面。
无论规模，建议圈定 2--3 个候选后，用真实项目做 PoC，至少验证四项：代码托管与评审 → 流水线触发与构建 → 制品归档 → 发布或回滚。PoC 别只测「能不能跑通 Hello World」，要用本团队真实分支策略、权限模型和发布窗口试一轮。自动化运维（Ansible/Terraform/监控）可在 CI/CD 跑通后再接，避免同时开太多战线。
五、常见问题
问：GitLab、GitHub 为什么在不同类别里都会出现？
五类按能力划分，不是产品互斥清单。GitLab、GitFox 等一体化平台一行说清即可，不必再单独选「代码托管」。GitHub 以托管为主，Actions 负责 CI/CD，所以在表里分两行出现------选型时看缺哪段：只有仓库没有流水线，补 Actions 或 Jenkins；已有 GitLab 底座，则无需重复采购托管能力。
问：一体化平台和 GitLab + Jenkins 组合有什么区别？
一体化把托管、CI/CD、制品、发布放在同一系统，数据默认可关联；组合方案各环节独立，灵活但要自己对接。选哪条，取决于现有投资和未来谁维护集成。
问：小团队适合哪种？
优先少维护、快上手：托管在 GitHub 就用 Actions；已有 GitLab 就用内置 CI；只有仓库缺流水线再考虑 Jenkins。小团队的核心是跑通闭环，不是堆工具名。
问：自动化运维算不算 DevOps 软件？
算，但是链路下游。CI/CD 解决「怎么构建和发布」；Ansible、Terraform 解决「环境怎么来」；Prometheus、Grafana 解决「上线后稳不稳」。选型时别和 CI/CD 混为一谈，分阶段建设更现实。
DevOps 软件没有放之四海而皆准的最好。先按五类看清缺哪一段，再按部署形态和合规要求圈 2--3 个候选，用 PoC 验全链路------比照着榜单买工具可靠得多。