Marico's space
手动部署有个很明显的规律：平时一切正常，直到某个周五有人赶着下班改了个东西，测试没跑直接推了上去，结果 bug 在周末凌晨炸了生产环境。这不是纪律问题，是流程问题——压力最大的时候，恰恰是手动流程最容易挂的时候。
GitHub Actions 解决这个问题的思路是把流水线直接放在仓库里。没有独立的 CI（持续集成）服务器要维护，没有乱七八糟的外部集成要配置。工作流文件就躺在 .github/workflows/ 目录下，触发条件就是 Git 事件。
持续集成（CI）就是在每次有人推送代码时自动运行测试，目标是趁上下文还新鲜、修复成本还低的时候把问题揪出来。持续交付（CD）就是在没有人工干预的情况下，把验证过的代码推到预发布或生产环境。
GitHub Actions 两个都能干。它是一个事件驱动的自动化平台：当仓库里发生什么事情——推送代码、打开 Pull Request、创建标签、定时任务——你定义的任务就会跑起来。
截至 2026 年初，这个平台每天处理超过 7100 万个任务，GitHub 市场上架了超过 10000 个各类 Actions，覆盖 32 个分类。你需要做的很多事情，都有现成的轮子可以用。
工作流就是 .github/workflows/ 目录下的一个 YAML 文件。一个仓库可以放任意多个工作流，文件名随意，但必须是 .yml 或 .yaml 结尾。
name: CI on: push: branches: [main] pull_request: branches: [main] jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Set up Node.js uses: actions/setup-node@v4 with: node-version: 20 cache: npm - name: Install dependencies run: npm ci - name: Run tests run: npm test
on 字段定义了什么事件会触发这个工作流。jobs 包含一个或多个工作单元。每个 job 会运行在一个 runner 上，默认情况下 runner 是 GitHub 临时提供的虚拟机，用完即销毁。job 内的 steps 按顺序在同一台机器上执行。
uses: actions/checkout@v4 这个 step 把仓库代码拉到 runner 上。没有它，机器是空的，代码根本不存在。这基本上是每个工作流里几乎必放的第一步。
GitHub Actions 对公开仓库完全免费，私有仓库每月有 2000 分钟的免费额度。个人项目和开源项目完全够用。
2026 年 1 月 GitHub 把 runner 价格下调了最高 39%。现在的标准 Linux runner 每分钟 $0.008，大型 runner 每分钟 $0.016。需要注意的是 macOS，每分钟 $0.08，是 Linux 的十倍。
ubuntu-latest runner 目前指向 Ubuntu 24.04。2026 年新增了几个预览镜像：Ubuntu 26.04（x64 和 arm64），以及 Windows 11 arm64 搭配 Visual Studio 2026。
2026 年 4 月，GitHub-hosted runner 的自定义镜像功能正式发布。这意味着你可以定义 runner 上预装了什么软件，而不用每次跑的时候再装一遍，对于系统依赖多的流水线来说能省不少时间。
凭证绝对不能写进 YAML 里。GitHub 在仓库和组织级别提供了 secrets 系统，对存储的内容加密，并在运行时注入为环境变量。在 Settings → Secrets and variables → Actions 里配置。
在工作流里引用的时候这样写：
- name: Deploy env: API_KEY: ${{ secrets.API_KEY }} run: ./deploy.sh
Environments 在 secrets 和部署之上加了一层控制。你可以用它定义一个 production 环境，任何使用这个环境的 job 在运行前都必须经过人工审批。这对于避免从 main 分支直接推代码然后自动部署到生产环境很有用。
jobs: deploy: environment: production runs-on: ubuntu-latest steps: - run: echo "Deploying to production"
在 production 环境里定义的 secrets 只能被声明了这个环境的 job 访问。
把 Azure 的密钥存在 GitHub 里能跑，但这带来了一个问题：需要定期轮换的凭证、会泄露的风险、而且权限通常比实际需要的要大。OIDC（OpenID Connect）能更干净地解决这个问题。
用 OIDC 的思路是：工作流在运行时直接向 GitHub 请求一个签名的 token，Azure 那边验证这个 token 来自配置的联合凭证，然后给这次特定的运行发放临时的访问凭证。根本不需要存什么 secret，凭证的生命周期刚好和 job 一样长。
jobs: deploy: permissions: id-token: write contents: read environment: production runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: azure/login@v2 with: client-id: ${{ vars.AZURE_CLIENT_ID }} tenant-id: ${{ vars.AZURE_TENANT_ID }} subscription-id: ${{ vars.AZURE_SUBSCRIPTION_ID }} - run: az webapp deploy --name my-app --resource-group my-rg --src-path ./dist
这三个登录用的值是变量（不是 secrets），因为它们本身不是凭证，只是服务主体的公开标识符。OIDC 在后台完成临时凭证的协商。
2026 年 4 月，GitHub Actions 的 OIDC 支持加入了仓库自定义属性作为 token 中的声明，这个功能正式发布。意味着可以在 Azure 里写更细粒度的访问策略，基于仓库属性而不是仅仅靠名称或分支。
每次运行都重新安装依赖是大多数流水线里最耗时的环节。actions/cache action 可以根据缓存 key 保存和恢复目录。
- uses: actions/setup-node@v4 with: node-version: 20 cache: npm
setup-node 带上 cache: npm 会自动处理 node_modules 的缓存。对于其他语言和工具，需要用 actions/cache 显式配置。
并发控制可以防止同一个工作流的多个运行重叠。如果你快速推送三次，没有并发控制的话三个运行会排队等着。加上这个配置，新运行到来时会取消正在进行的那个：
concurrency: group: ${{ github.workflow }}-${{ github.ref }} cancel-in-progress: true
在功能分支上，取消前一个运行是合理的。但在 main 分支上你可能不想取消，因为每次运行都会产出部署产物。可以根据 github.ref 做条件判断。
GitHub Agentic Workflows 在 2026 年初进入公开预览，用于自动化 issue 分类、CI 失败分析、文档更新等任务。7 月又上线了一个集成：现在可以直接在工作流里用内置的 GITHUB_TOKEN 运行 GitHub Copilot CLI，不需要创建或存储个人访问令牌。Agentic Workflows 已经应用了同样的原则，现在扩展到了 Copilot CLI。
还有两个安全方面的变化。GitHub Enterprise Cloud 带数据驻留功能的版本从 2026 年 7 月 31 日开始强制执行自托管 runner 的最低版本要求，低于最低版本的 runner 将无法注册或执行工作流任务。不带数据驻留功能的 GitHub Enterprise Cloud 从 2026 年 9 月 25 日开始执行相同要求。
另一个变化针对供应链安全：GitHub Actions 现在会自动暂停被识别为可能有恶意的工作流运行，需要具有写权限的协作者明确批准后才能执行。这防止了凭证泄露后攻击者可以在没有人工干预的情况下触发工作流。
这三个变化对配置正确的标准流水线没有影响。但对于运行着过时自托管 runner 的团队，以及接受外部贡献但没有提前审查的开源项目来说，还是挺重要的。
GitHub Actions 的学习曲线不在理解 YAML 语法，而在于理解执行模型：哪些东西在 steps 之间共享状态、哪些不共享，什么时候拆成多个 job 什么时候不该拆，以及 github.* context 里有什么信息可以用。
官方文档质量不错，但覆盖的面太广，对刚入门的人来说不容易找到合适的切入点。最实用的起点是微软 Learn 上 GitHub Actions 结合 Azure 的快速入门，直接对应大多数实际云端部署场景：
👉 GitHub Actions 与 Azure 集成快速入门
这篇文章的信息基于撰写时的官方 GitHub 文档和经过验证的来源。GitHub 可能随时更新定价、功能和平台行为。在基于本文内容做决策之前，请查看 docs.github.com 上的最新官方文档。