技术精进

抛弃Jenkins后，我用GitHub Actions帮团队省下80%维护成本

记得三年前，作为一家20人规模初创公司的技术负责人，我最害怕的就是周五下午。

那时候我们还在用一台老旧的阿里云ECS跑Jenkins。每当有新人入职，我就得花半天教他怎么配置构建参数；每隔两个月，Jenkins的插件升级就会搞崩整个流水线，导致我要在深夜盯着报错日志发愁。

我曾坚定地认为：只有自建CI/CD系统才足够安全、可控。 直到2021年的一次"灾难"——由于构建节点磁盘爆满，我们错过了一个紧急修复的黄金发布窗口，导致客户投诉量激增。

那天之后，我痛定思痛，决定带领团队从重型运维转向轻量化DevOps，全面迁移至GitHub Actions。今天这篇复盘，就是想聊聊对于没有专职运维的中小团队，如何用最低的成本，搭建一套不输大厂的自动化发布流。

算清楚"隐形账"：免费的往往是最贵的

配图

很多技术主管在选型时会陷入一个误区：开源软件免费，所以成本低。

在我们团队只有5个开发的时候，维护Jenkins似乎没什么问题。但当团队扩张到15人，后端、前端、移动端项目混杂时，问题爆发了。

2021年Q3，我做了一次详细的成本核算：

  • 显性成本：一台4核8G的构建服务器，每年约3000元。
  • 隐性成本：我每周至少花3小时在维护环境、升级插件、清理磁盘、处理构建排队上。按照时薪计算，这部分人力成本每年超过5万元。更别提因为构建失败导致全组人停下来等修复的"等待成本"。

迁移到GitHub Actions后，这笔账发生了惊人的变化。

对于公共仓库，GitHub Actions完全免费；对于私有仓库，Free计划每月赠送2000分钟构建时间。即使是我们这样每天提交频次较高的团队，配合Pro版（每人$4/月），只要配置得当，几乎不需要额外购买构建时长。

“中小团队的核心资源是开发者的注意力，而不是服务器资源。任何能让开发者少操心的工具，都是在省钱。”

告别"黑盒"：让流水线代码化 (Pipeline as Code)

以前用Jenkins时，构建逻辑都藏在复杂的UI配置里。

配图

有个叫小李的后端同事，想给自己的微服务加一个简单的代码风格检查（Lint）。他得先找我要Jenkins权限，然后在一堆输入框里摸索，最后因为配错了一个环境变量，把整个测试环境搞挂了。

CI/CD不应该只是运维人员的"特权"，它应该是代码的一部分。

迁移到GitHub Actions后，所有的构建逻辑都变成了一个 .github/workflows/main.yml 文件。这带来了两个立竿见影的改变：

  1. 版本控制：流水线的每一次修改都有Git记录，谁改的、改了什么、什么时候改的，一清二楚。
  2. 全员参与：现在，连刚入职的实习生都能照葫芦画瓢，通过提交PR来修改构建流程。

这里分享一个我们目前正在使用的、针对Node.js服务的标准化配置模版。它包含了缓存优化，这也是降低成本的关键：

name: Production Build
on:
  push:
    branches: [ "main" ]
    # 关键点：只在相关文件变动时触发，节省构建分钟数
    paths-ignore:
      - '**.md'
      - 'docs/**'

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '18'
          # 开启缓存，大幅减少依赖下载时间
          cache: 'npm'
          
      - name: Install Dependencies
        # 使用 ci 命令比 install 更快更稳定
        run: npm ci
        
      - name: Run Tests
        run: npm test
        
      - name: Build
        run: npm run build

这个简单的配置，让我们的平均构建时间从Jenkins时代的8分钟，缩短到了3分钟以内。

拒绝"乱收费"：精细化控制每一分钟

刚开始迁移时，我也踩过坑。第一个月，我们还没到月底就收到了GitHub的额度耗尽提醒。

排查后发现，90%的浪费来自于无效构建。

比如，前端改了一个 README.md 文档，却触发了后端API的完整构建和测试；或者同一个PR由于反复提交代码，导致同时跑了5个并行的构建任务。

为了解决这个问题，我总结了三个"省钱妙招"，一直沿用至今：

  1. 路径过滤（Path Filtering）：如上文代码所示，严格配置 paths 或 paths-ignore。文档变动绝不触发代码构建。

  2. 并发控制（Concurrency Control）：这是个神器。当同一个分支有新的提交推上来时，自动取消正在进行的旧构建。这一个配置帮我们节省了约30%的分钟数。

    concurrency:
  group: $-$
  cancel-in-progress: true

  3. 善用Cache：无论是npm、maven还是docker layer，都要利用 actions/cache。我亲测，加上缓存后，构建过程中最耗时的"下载依赖"环节几乎变成了秒级。

通过这套组合拳，即使现在我们的代码库规模翻了一倍，每月的构建费用依然控制在Pro订阅费之内，几乎没有产生额外的分钟数账单。

写在最后

从自建Jenkins到拥抱GitHub Actions，不仅仅是工具的替换，更是团队DevOps文化的升级。

我们不再需要一个专门的"发布管理员"，每个开发者在提交代码的那一刻，就对自己代码的构建和测试负责。我也终于把周五下午的时间解放出来，可以安安心心地做一些技术预研，而不是盯着进度条祈祷不要报错。

配图

对于正在纠结的中小团队，我的建议很直接： 如果是100人以下的研发团队，且没有复杂的合规（如金融级内网隔离）要求，尽早切到GitHub Actions或GitLab CI。 别让维护工具本身，成为了你们的负担。

最后做个小调查： 在CI/CD选型上，你更看重哪一点？ A. 完全的可控性（哪怕麻烦点，也要数据都在自己服务器上） B. 极致的效率与低维护（托管服务真香，少折腾才是硬道理）

欢迎在评论区留下你的选择。

如果你准备开始行动，建议从以下3步着手：

  1. 盘点高频痛点：找出目前部署流程中最耗时、最容易出错的环节（通常是环境配置或依赖安装）。
  2. Copy & Paste：不要从零写，去GitHub Marketplace找一个成熟的Action模版，先跑通"Hello World"。
  3. 配置缓存：这是让体验从"能用"变成"好用"的关键一步，务必在第一时间加上依赖缓存。
© 2026 SelfTechHub