CI/CD 与 GitHub Actions 自动化部署实战

Tue, 15 Sep 2026 17:20:00 +0800

CI/CD（持续集成与持续交付/部署）是一种现代软件工程方法论，通过在代码仓库中自动化执行构建、测试与部署流水线，实现从代码提交到线上生产环境的无人值守闭环。

1. CI/CD 简介

在传统的网站与前后端项目运维中，最普遍的人工操作流程往往是：本地编写代码 → 本地执行编译构建打包 → 打开 FTP/SFTP 传输软件（如 FileZilla、WinSCP 或服务器文件管理器） → 拖拽上传并覆盖服务器目标目录。

这一原始模式存在三个显著工程痛点：

操作机械繁琐：每次细微的代码更新都要手动重复“构建-传输-覆盖”流程，严重打断研发心流。
环境配置耦合：本地开发环境的私有配置（如本地调试域名或测试环境变量）容易在打包时误带入生产，污染线上运行环境。
残留冗余废弃文件：手动文件覆盖仅处理“新增”和“替换”，一旦在本地删除了旧文件或重构了路由目录，服务器目录中残存的废弃历史文件无法自动清理。

CI/CD 正是为了将这一繁琐、易出错的人工运维流程彻底解脱为无人值守的自动化闭环。

1.1 什么是 CI 与 CD

CI/CD 并非单一软件，而是一种敏捷软件工程实践方法，通常由两个紧密衔接的阶段组成：

阶段	英文全称	核心职责	项目映射举例
CI	Continuous Integration （持续集成）	代码频繁合并至主干，并在云端隔离环境自动执行语法检查、依赖安装、单元测试与编译打包，尽早暴露冲突与语法缺陷。	代码推送到主分支后，云端自动拉取代码并运行构建命令进行编译与产物完整性验证。
CD	Continuous Delivery （持续交付）	产物构建测试通过后，自动打包为可随时发布的标准交付包（Release/Artifact），等待人工确认后上线。	编译产物打包存入云端交付物仓库待命，由运维或负责人点击确认发布。
CD	Continuous Deployment （持续部署）	无任何人工干预，只要前面的集成验证通过，新版本立即自动推向真实的生产服务器，实时生效。	编译产物无需人工点击，直接由云端通过 SSH/rsync 增量覆盖生产服务器的部署目录。

2. GitHub Actions 核心概念

GitHub Actions 是 GitHub 官方集成的 CI/CD 自动化平台。它免去了自建 Jenkins 调度节点的高昂维护成本，直接在代码托管仓库内以 YAML 声明式语法编排流水线。

2.1 核心组成要素

GitHub Actions 的运行逻辑基于五个核心抽象概念：

概念/组件	对应配置语法	描述与核心职责
Workflow	name / 文件名	工作流，存放在 .github/workflows 目录下，定义一次完整的自动化任务集合。
Event	on	触发器，定义何时激活工作流（如 push、pull_request 或手动 workflow_dispatch）。
Jobs	jobs	任务单元，由一个或多个 Job 组成。不同 Job 默认并行执行，也可声明依赖串行运行。
Runner	runs-on	运行容器/虚拟机，平台动态分配的纯净环境（如 ubuntu-latest），任务完成后自动销毁。
Steps / Action	steps / uses	步骤与动作，Job 内部由多个 Step 顺序执行，可直接复用开源社区沉淀的 Action 模块。

Harness 工程架构深度解析

Tue, 09 Jun 2026 20:30:00 +0800

从架构视角深入解读 Harness 的设计哲学，帮助工程师建立对现代 CI/CD 平台的认知框架

一、Harness 到底是什么

一句话：Harness 是一个构建在 Kubernetes 之上的、以 Delegate 为核心执行引擎的、SaaS 化的软件交付平台。

这句话里有三个关键词，每一个都值得展开。

1. 构建在 Kubernetes 之上

Harness 的控制平面（Control Plane）是一组微服务，运行在 Kubernetes 集群中。这意味着：

弹性伸缩是天然能力，不是事后补丁
多租户隔离通过 K8s 的 namespace 和资源配额实现
服务治理依赖 K8s 原生的服务发现和负载均衡

这不是什么了不起的事——几乎所有现代 SaaS 产品都跑在 K8s 上。但关键在于，Harness 把 K8s 的能力向下暴露给了用户：你的 Pipeline 可以直接操作 K8s 集群进行部署，而不是通过一层中间转换。

2. Delegate 是核心执行引擎（重点）

这是理解 Harness 最关键的一个概念。

Delegate 是一个运行在你基础设施中的进程，负责执行 Pipeline 中的所有任务。它不是 Harness 帮你跑的——它跑在你的环境里。

为什么要这样设计？因为软件交付涉及的操作，绝大多数都需要访问内网资源：代码仓库、制品库、K8s 集群、数据库、云账号。如果这些操作全部由 Harness 的 SaaS 控制平面来执行，就意味着你的内网资源必须对 Harness 开放——这在安全合规层面几乎不可接受。

Delegate 的架构解决了这个问题：

┌─────────────────────────────────────────────────────┐
│ Harness SaaS控制平面 │
│ (Pipeline 编排、状态管理、UI、API) │
└──────────────────────┬──────────────────────────────┘
 │ 出站连接（Delegate 主动拉取任务）
 │ ← 不需要入站端口暴露
┌──────────────────────▼──────────────────────────────┐
│ 你的基础设施 │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ Delegate │ │ Delegate │ │ Delegate │←可部署多个 │
│ └────┬─────┘ └────┬─────┘ └────┬─────┘ │
│ │ │ │ │
│ ┌───▼───┐ ┌────▼───┐ ┌────▼───┐ │
│ │K8s集群 │ │代码仓库 │ │云账号 │ │
│ └───────┘ └────────┘ └────────┘ │
└─────────────────────────────────────────────────────┘

核心设计要点：

CI/CD on Blog