Gitlab
GitLab 是 Cloud-Neutral Tool Map 中 ② 交付与变更控制（IaC & DevOps）** 这一层里，少数真正把“代码、协作、CI/CD”整合为一个工程系统的平台型项目。 它关注的并不是“怎么把一次流水线跑通”，而是一个更现实的问题：
当团队规模扩大后，交付体系是否还能被统一治理。
项目主要特性
- 代码托管 + Issue + MR + CI/CD 一体化
- 内建 CI 引擎（GitLab CI），无需外部系统
- Pipeline 即代码**（
.gitlab-ci.yml） - 权限 / 项目 / 组织级治理模型完整
- 支持自托管**，不绑定云厂商
- *与 IaC / GitOps 生态天然协同
GitLab 的核心价值不是“CI 很强”，而是把交付能力纳入平台治理范围。
与其他主流方案的工程对比
不讨论 Jenkins/JenkinsX（属于上一代工具范式，过去时）
GitLab vs GitHub Actions
| 维度 | GitHub Actions | GitLab |
|---|---|---|
| 工作流 / CI 能力 | 工作流语言成熟、表达力极强 | CI 深度内嵌于平台 |
| 平台取向 | SaaS 优先，企业级能力深度绑定 GitHub | 平台能力完整 |
| 自托管能力 | 自托管能力有限（Runner ≠ 平台） | 自托管能力完整 |
| 适用环境 | GitHub 生态内优先 | 更适合对合规、网络、数据有要求的环境 |
| 工程定位总结 | 更像“工作流引擎” | 更像“交付平台” |
GitLab vs Gitea + 外部 CI
| 维度 | Gitea + 外部 CI | GitLab |
|---|---|---|
| Git 服务定位 | 轻量、克制、工程友好 | 平台级能力更完整 |
| 适用团队 | 更适合“只想要一个 Git Server”的团队 | 面向多项目、多团队 |
| CI 实现方式 | CI 通常通过 Woodpecker / Actions 兼容实现 | 内建 CI |
| 项目治理 | 能力有限 | 项目治理、权限、流程一体化 |
| 运维与资源成本 | 较低 | 运维与资源成本更高 |
| 工程定位总结 | 解决“简单可靠” | 解决“规模治理” |
优缺点
| 优点 | 局限 |
|---|---|
| 一体化 DevOps 平台 | 资源占用高 |
| 自托管、Cloud-neutral | 运维复杂度高 |
| 权限与组织模型成熟 | 小团队可能显得过重 |
| CI/CD 深度集成 | 升级与维护成本需规划 |
适用场景
| 适合 | 不适合 |
|---|---|
| 中大型团队 / 多项目协作 | 只需要轻量 Git 托管 |
| 私有云 / 内网 / 合规环境 | 极简 CI 场景 |
| 需要统一交付治理 | 不愿承担平台运维 |
| IaC / GitOps 体系 |
工程判断
GitLab 并不是“CI 工具的替代品”， 而是明确站在 “交付平台与变更治理” 这一工程责任边界上：
当交付不再只是跑流水线，而是需要被统一管理、审计与约束时，GitLab 才真正显现价值。
在 Cloud-Neutral 体系中，它更适合的位置是：
- Terraform 定义资源，
- GitLab 负责协作与交付平台，
- Argo CD 控制运行态。
项目地址
- GitHub：https://github.com/gitlabhq/gitlabhq
- 官网：https://about.gitlab.com
- 文档：https://docs.gitlab.com
如果说 GitHub Actions 是一门强大的工作流语言，那 GitLab 更像是一座把交付能力“制度化”的工厂。更多工程判断，见「云原生工坊 · 工程技术雷达」。
