CI/CD 工具选型

主流工具一览

工具	模型	自托管	学习曲线	适合
GitHub Actions	YAML / 共享 runner / self-hosted runner	部分（runner）	低	已用 GitHub 的项目
GitLab CI	YAML / 自带 runner	完整自托管	低	用 GitLab 的项目
Jenkins	Pipeline (Groovy) / Plugin 生态	完整	高（插件多 + 老）	老项目 / 强自定义
Buildkite	YAML + agent 在自己机器	Hybrid（控制平面在云）	中	重度自托管但不想运维 controller
CircleCI	YAML / 云 + self-hosted	部分	低	通用项目，独立工具
Drone	YAML / docker 化	完整	低	轻量 / 自托管
Tekton	K8s CRD	K8s 原生	中-高	已重度用 K8s
Argo Workflows	K8s CRD	K8s 原生	中	数据 / ML 流水线

Travis CI 和 Bamboo 在新项目里基本不见了。CircleCI 仍活跃但生态没 GHA 强。

跑同一组测试在 N 种环境（语言版本 / OS）：

# GitHub Actions
strategy:
  matrix:
    python: ["3.10", "3.11", "3.12"]
    os: [ubuntu-latest, macos-latest]

矩阵跑得起来 = 工具基本够用。

GHA 的 workflow_call、GitLab 的 include、Jenkins 的 shared library——都是把"建镜像 / 部署 / 通知 Slack"等通用步骤抽出来，避免每个仓库复制粘贴。

计费策略经常变——选型时去官网看当下定价，别信几年前的博客。

每个仓库一份独立的 90 行 yaml → 改成 reusable workflow + 共享 action
CI 配置 commit 到 default 分支才生效 → 测试期间会污染 main
失败的 job 没有通知 → 加 Slack / Teams / 邮件
CI 跑很慢但没人看时间 → 装 GitHub Actions Workflow Insights / GitLab CI Pipeline Stats

新项目：

GitHub 仓库 → GitHub Actions（默认）
  ↓
后期加自托管 runner 跑大 build / 跨环境测试
  ↓
真有合规需求再考虑迁 GitLab Self-hosted

不要一开始就上 Jenkins——大多数团队不需要那个复杂度。