CI/CD 平台选择：GitHub Actions、GitLab 与 Jenkins

GitLab CI/CD、GitHub Actions 和 Jenkins 都能把代码提交转成可重复的检查与交付流程。选型应先看代码托管位置、执行环境、维护能力和权限边界，再比较功能数量。

三个平台的组成

维度	GitHub Actions	GitLab CI/CD	Jenkins
常见配置入口	.github/workflows/*.yml	.gitlab-ci.yml	Jenkinsfile
执行组织	workflow、job、step	pipeline、job、stage/依赖图	pipeline、stage、step
执行机器	GitHub 托管或自托管 runner	实例提供或自行注册 runner	controller 调度 agent
复用方式	actions、可复用 workflow	include、CI/CD components	shared library、插件
运维重点	托管配额或自托管 runner 隔离	GitLab/runner 配置与资源	controller、agent、插件兼容和备份

基本模型分别见 GitHub Workflows、GitLab CI/CD 和 Jenkins Pipeline。GitLab runner 可以运行在物理机或虚拟机，扩展并不以 Kubernetes 为必要条件。

应按什么问题选择

• 仓库已托管在哪里，权限与代码审查是否能复用？
• 构建需要 Windows、Linux、GPU、专用硬件还是内网服务？
• 团队是否能够维护自托管执行器、插件和升级兼容？
• 并发数、执行时长、缓存、产物存储和网络流量如何计费？
• 出错时能否定位到准确提交和构建产物，能否安全回滚？

不能笼统断言某个平台“最快”或“免费”：性能取决于机器、队列、缓存和流水线；价格与配额会随套餐变化。即使执行器自托管，也仍有机器和维护成本。

三者都需要的流程设计

触发事件 → 检出明确提交 → 安装锁定依赖 → 检查与测试 → 构建产物
         → 审核部署权限 → 部署明确产物 → 健康检查 → 保留可回滚版本

避免部署阶段重新拉取一个与测试阶段不同的“最新 main”。缓存可加速重建，但交付应使用可追溯的产物与提交号。部署需要互斥，旧任务不应把新版本覆盖回去。

凭据与不可信代码

Secret/凭据库用于受控传递敏感信息，不保证脚本输出或第三方 action 永远不会泄漏。应限制令牌权限、保护部署环境、审查外部组件，并让不可信分支的测试与生产凭据隔离。日志脱敏不能替代权限设计。

本篇保留原比较笔记的选型维度，去掉无测量依据的绝对性能、成本排名，以及“配置 Secret 即完全安全”的说法。