AI时代，CI/CD的贤者时间

GitLab 为什么重？

原因很简单：它试图把所有东西都塞进一个“大房子”里。从代码托管、CI/CD流水线，到镜像仓库、制品库，再到Wiki、Issue跟踪甚至监控，一应俱全。你需要的功能它都有，你暂时用不上的，它也预先打包好了。

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

这其实是上一个软件时代的典型产品逻辑——功能越全面，竞争力似乎就越强。

但AI时代的玩法，已经变了。

AI时代软件的核心逻辑，转向了灵活拼装与确定性并存。每个组件专注做好一件事，通过清晰的标准接口进行组合。需要什么，就接入什么；不需要的，一个都不必引入。整套系统的行为因此变得可预测，每个节点的输入输出明确，彻底避免了因为某个“大而全”的平台悄悄升级了某个子模块，而导致整个流水线行为出现不可预知的偏差。

这可以说是微服务架构思想的一种延伸，甚至走得更远——连CI/CD工作流定义本身，也可以成为一个可插拔、可替换的标准化组件。

那么用户界面呢？

一个试图容纳所有功能的“All in One”平台，其界面设计必然走向臃肿。而AI时代的界面，理应围绕实际需求动态呈现。开发者真正关心的，往往是“哪条流水线正在运行”、“哪个环境出了告警”、“最近三次发布的结果如何”。展示这些核心信息，其实并不需要一个庞大复杂的界面，一个简洁、专注的Web页面往往就足够了。

那么，确定性究竟从何而来？

它不依赖于某个特定的界面，也不源于某个垄断性的平台。真正的确定性，建立在四块基石之上：依赖锁定在具体的提交SHA上、执行环境完全容器化、流水线定义本身版本化并存入Git、以及每一个构建产物都能清晰追溯到对应的代码提交。只要这四件事做到位了，至于使用什么前端界面来查看和管理，反而成了次要问题。

GitHub Actions 为什么做对了

我们可以逐层来看它的设计。

在触发层，它的设计非常清晰且强大。不仅仅是代码推送（Push）能触发工作流，几乎任何GitHub上的事件——Issue评论、PR打上标签、甚至是定时任务——都可以作为起点。这种事件驱动的灵活性，是许多传统CI系统所欠缺的。

Runner层则是关键性的创新。GitHub托管的Runner开箱即用，用户无需操心服务器运维，免费额度足以覆盖大多数个人或中小项目的需求。对于有特殊需求的场景，自托管Runner的部署也极其简单，一个二进制文件即可完成注册，支持从Linux、macOS到Windows乃至ARM架构的全平台覆盖。这一层，几乎将CI/CD的底层运维成本降到了零。

而Action生态，构成了其深厚的护城河。市场上已有成千上万个预先构建好的Action，覆盖了从代码检查、打包构建到云端部署的各个环节。这意味着开发者通常无需再编写复杂的Shell脚本，或记忆各种命令行工具的参数。

此外，Job之间的文件共享无需搭建复杂的NFS，跨Workflow的依赖复用避免了重复下载。密钥（Secrets）管理被内置，支持按仓库、环境、组织三级精细管控，并在日志中自动脱敏。这些细节，单独看或许都不算革命性突破。

但将它们流畅地组合在一起，所带来的无缝体验，恰恰体现了优秀产品设计的价值——不在于某个单点功能多么惊艳，而在于整个系统没有明显的短板。

然后，连 YAML 都不用写了

GitHub在2024年底开源了一个名为gh-aw（GitHub Agentic Workflows）的项目，将体验又向前推进了一步。

其核心思路非常直观：开发者只需用Markdown格式的自然语言描述想要完成的任务，AI会将其翻译成GitHub Actions能够执行的逻辑，并在Actions环境中运行起来。

这不再是“AI辅助补全YAML”，而是彻底跳过了编写YAML配置的步骤，直接用人话描述意图。

例如，用一段简单的Markdown写下：“运行单元测试，构建Docker镜像，推送到私有仓库，并在Slack频道发送通知”，这就构成了一个完整的工作流定义。gh-aw会解析这段描述，生成对应的执行计划，并在Actions Runner上付诸实施。

安全性方面也并未妥协。所有依赖的Action都会被锁定到具体的提交SHA（而非易变的标签），有效防范供应链攻击。任何涉及“写”操作的关键步骤，都可以设置显式的人工审批门禁，且网络默认处于隔离状态。

从“编写配置”到“描述意图”，这无疑是一次质的飞跃。

这套东西能搬到公司内部吗

完全可以，而且实现起来可能比想象中更简单。

许多团队一提到“私有化CI/CD”，思维定式就指向了GitLab这类全栈方案。GitLab确实像个功能齐全的大礼包，但问题在于：你的团队真的需要礼包里的所有东西吗？

对于大多数公司而言，核心需求其实非常聚焦：安全的代码存储与权限管理、能稳定运行的流水线、以及成品的存储与分发。

对应到最小化的技术选型，路径非常清晰：使用Gitea或Forgejo进行代码托管，用Gitea Actions来运行流水线，用Harbor存储Docker镜像。这三个都是成熟的开源项目，从三台服务器起步就能搭建起来。更重要的是，Gitea Actions的语法与GitHub Actions高度兼容，在GitHub上编写的工作流，稍作调整就能迁移到内网环境中运行。

那么，AI能力如何内化呢？

这确实是私有化部署中最具挑战的一环。gh-aw背后调用的通常是GitHub Models（基于Azure OpenAI），要搬到内网，就需要替换这一层。通常有两个选项：接入企业内网已有的LLM API服务（许多公司已部署了私有化的Qwen或DeepSeek模型），或者使用Ollama等工具在本地运行轻量级模型。对于生成Workflow YAML这类任务，参数较小的本地模型已经足够胜任。

此外，别忘了nektos/act这个实用工具。它可以在本地完全模拟GitHub Actions的执行环境，允许开发者在将代码推送到远程仓库之前，就在本地调试和验证工作流，从而节省大量“提交-等待-查看报错”的循环时间。

至此，一条完整的私有化链路已经清晰：从自然语言Markdown开始，经由gh-aw生成YAML配置，通过act在本地验证，最终提交到Gitea Actions正式执行，构建产物推送到Harbor，并部署至Kubernetes集群。这条链路一旦跑通，一个由AI驱动的内部CI/CD体系便初具雏形。

CD 还差几块

上述组合拳，基本解决了持续集成（CI）的问题。但在持续部署（CD）方面，还有几个关键环节需要补齐。

首先是Runner的弹性问题。自托管的Runner默认是静态资源，低谷期闲置浪费，高峰期又可能排队。解决方案是将其与Kubernetes集群集成，利用Actions Runner Controller（ARC）这类工具，按需动态创建Pod作为临时Runner，任务完成后立即销毁。这才是面向生产环境的做法。

其次是多环境发布流程。一个完整的发布链路至少需要开发（dev）、预发（staging）和生产（production）三个环境。利用GitHub Actions的environment特性可以实现环境隔离，每个环境可以配置独立的密钥和保护规则，例如，对生产环境的部署操作强制要求人工审批。

再者是发布策略的支撑。蓝绿部署、金丝雀发布、滚动更新——这些高级策略本质上不属于CI/CD工具的职责范畴，而应由部署层来实现。Kubernetes本身支持滚动更新，而Argo Rollouts等专业工具则能很好地处理金丝雀和蓝绿发布。CI/CD工具的角色，应该是可靠地触发部署流程，至于流量如何切换、版本如何灰度，则应交给专业的部署层工具，职责分明。

GitOps模式为此提供了一种更优雅的范式。与其让CI/CD流水线通过SSH等方式直接操作服务器，不如让它只专注做一件事：更新Git仓库中声明的部署配置（例如，修改Kubernetes YAML文件中的镜像标签）。然后，由ArgoCD这样的GitOps工具持续监听这个仓库，一旦发现配置变更，便自动将其同步到实际的Kubernetes集群中。

这样做的好处显而易见：整个系统的部署状态完全由Git仓库中的代码定义，可审计、可回滚、状态一目了然。出现问题后，第一时间不是找人问，而是直接查看Git提交历史。

说句实话

流水线这个领域，技术层面确实已经被挖掘得非常充分了。

从Jenkins时代的插件化，到GitLab CI的集成化，再到GitHub Actions的生态化，乃至现在AI开始生成工作流，每一轮演进都伴随着激烈的竞争。但平心而论，大家做出来的东西，核心功能和体验越来越趋同，很难再形成碘伏性的技术壁垒或差异化优势。

从这个角度看，这个赛道本身，或许已不值得投入大量资源去“内卷”。

但是，话又说回来。

就是这些看似“被玩烂了”的基础能力，你去审视国内很多公司的实际现状，会发现差距依然巨大：部署靠手动操作，依赖个人的记忆和冗长的SOP文档；测试环境与生产环境共用一套配置，仅通过域名区分；没有构建产物管理，每次发布都重新构建，结果无法复现；回滚等同于重新执行一遍复杂的上线流程；共享的Jenkins服务器上被随意安装各种依赖；密钥（Secrets）甚至以明文形式写在配置文件里，并提交到了代码库中。

这并非刻意指责，而是一种相当普遍的现象。

智能时代已然来临，AI生成工作流、自然语言驱动流水线，这些都不是概念，而是正在发生的现实。

然而，如果一个团队连最基本的流水线规范都未建立，环境隔离形同虚设，密钥管理一片混乱，那么空谈智能时代的先进工具，又有多大实际意义呢？

连及格线都尚未达到，便不必急于讨论如何追求满分。

当务之急，是先把一条标准、可靠的自动化流水线跑通，把不同环境严格隔离，建立起规范的密钥管理体系。把这些基础工程实践夯实之后，再来探讨如何引入gh-aw，如何拥抱AI驱动的CI/CD。

到那时你会更深刻地体会到：AI能帮你生成的，终究是那一段段YAML配置；而真正的工程能力与体系根基，依然需要靠团队自己一砖一瓦地构建起来。

工具在飞速进化，但底层的工程逻辑，始终稳固。