自建 CI CD 教程 UserStory

原创

gavin1024

发布于 2026-11-02 14:29:40

1890

摘要： 自建 CI/CD 让代码提交后自动构建、测试、部署。基于已有的 Gitea 代码仓库，用 Gitea Actions 配合 Runner 即可搭一套轻量流水线：注册 Runner、在仓库里写工作流 YAML，推送代码即自动触发。本教程讲清原理与从零搭通一条流水线的完整步骤。

自建 CI/CD 的目标是：代码一推送，服务器就自动帮你构建、测试、部署，不用再手动操作。如果你已经用 Gitea 托管代码，最顺的方案是用 Gitea Actions——它的工作流写法与 GitHub Actions 高度相似：在仓库里放一个工作流 YAML、注册一个 Runner（执行任务的机器），推送代码就自动触发流水线。下面从原理讲到搭通一条完整流水线。

一、CI/CD 是什么，解决什么问题

CI/CD 指持续集成（Continuous Integration）和持续交付/部署（Continuous Delivery/Deployment）。没有 CI/CD 时，每次改完代码要手动构建、手动测试、手动传到服务器，既慢又容易出错。有了 CI/CD，这些步骤被写成自动化流水线：提交代码 → 自动拉取 → 自动构建 → 自动测试 → 自动部署，全程无需人工干预。

它适合任何有频繁发布需求的团队和项目，能显著减少重复劳动和人为失误。

二、方案选择与前置条件

自建 CI/CD 的方案有多种，本文采用与 Gitea 配套的 Gitea Actions，理由是：如果代码已经托管在 Gitea 上，Actions 开箱即用、无需再装独立的 CI 系统，工作流语法贴近 GitHub Actions、迁移成本低。

前置条件：已有一个可用的 Gitea 实例并托管了代码仓库（参见 Gitea 搭建教程）；一台能跑构建任务的机器做 Runner（可与 Gitea 同机或单独一台 CVM）。

三、准备工作与规格建议

CI/CD 的资源消耗主要在 Runner 执行构建任务时——编译、打包、跑测试都吃 CPU 和内存。构建任务重时，Runner 建议用独立的、规格高一些的实例，避免和 Gitea 抢资源。

腾讯云服务器 CVM 提供弹性伸缩和多样化规格，适合做 Runner：平时小规格、构建高峰按需升配。准备一台装好 Docker 的 CVM 作为 Runner 环境。

四、在 Gitea 中启用 Actions

Gitea Actions 默认可能未启用，需在 Gitea 配置中开启（在 Gitea 的配置文件中启用 actions 相关配置，具体以 Gitea 官方文档为准），重启 Gitea 生效。启用后，仓库设置里会出现 Actions 相关选项。

五、注册 Runner

Runner 是实际执行流水线任务的程序。核心步骤：

在 Gitea 后台或仓库/组织的 Actions 设置里，获取 Runner 的注册地址和注册 token；在作为 Runner 的 CVM 上，下载并运行 Gitea Act Runner，用注册地址和 token 把它注册到 Gitea；注册成功后，Gitea 的 Runner 列表里会显示这台 Runner 为在线状态。

Runner 建议用 Docker 方式运行，构建环境干净、隔离性好。

六、编写工作流并触发

在代码仓库里创建工作流文件 .gitea/workflows/ci.yml，写一个最简流水线：

name: CI
on: [push]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: 构建
        run: |
          echo "开始构建"
          # 这里换成你的实际构建命令，如 npm install && npm run build
      - name: 部署
        run: |
          echo "开始部署"
          # 这里换成你的实际部署命令

说明：on: [push] 表示每次推送代码就触发；jobs 下是具体步骤，checkout 拉取代码，后面的步骤换成你项目真实的构建、测试、部署命令。

把这个文件提交并推送到仓库，Gitea 就会自动触发流水线，Runner 领取任务并按步骤执行。在仓库的 Actions 页面能看到运行记录和每一步日志。