CI/CD 演进
在这套 Homelab 里，CI/CD 是我最想单独展开讲的一部分。因为它体现的不是“我把几个服务装起来了”，而是我有没有能力把代码托管、构建、镜像管理、版本更新和集群部署连成一条能长期重复运行的交付链路。
我为什么单独拆一页
很多 Homelab 页面会展示“我跑了哪些服务”，但对我来说，更重要的是我能不能把服务背后的交付方式也一起搭起来。真正让我觉得这套环境有价值的，不是机器数量，而是我已经在里面跑过两种不同风格的交付链路：
- 先前模式：偏本地一体化，强调我能在本地闭环跑通完整流水线
- 现在模式：偏云端协同，强调我能根据网络、成本和维护边界重构这条链路
先前模式：本地一体化 CI/CD
最早那套方案，核心目标其实很直接：我想验证本地能不能自己跑起一整套像样的交付系统。
这套模式里，重点不是某一个工具本身，而是这些环节已经能在本地形成一个完整闭环：
Gitea负责代码托管和触发入口Jenkins负责构建、测试和流水线编排Harbor + Trivy负责镜像管理和基础安全扫描Jenkins会把部署版本回写到 Git 仓库Argo CD监听 Git 变更，把镜像版本同步到local.k8s
这套模式让我真正练到的东西
- 我能把代码、镜像、部署三条线接起来：不是单点工具使用，而是完整闭环
- 我能在本地搭出平台式交付环境：代码仓库、CI、镜像仓库、GitOps、K8s 都能串起来
- 我理解 GitOps 不是“装个 Argo CD”：关键在版本更新、仓库回写和最终部署之间的关系
我在这套模式里真正搭过的关键动作
- 用
Webhook把Gitea提交事件接到Jenkins，把“代码变化”变成“自动触发流水线” - 让
Jenkins在构建完成后推送镜像到Harbor，再接Trivy做基础扫描 - 把部署版本从流水线回写到 Git 仓库，而不是直接在集群里手改镜像标签
- 让
Argo CD只负责同步 Git 中声明的目标状态，保证 CI 和 CD 的职责边界清楚
这套模式的优点
- 所有东西都在本地，实验自由度高
- 很适合验证“整条链路我能不能自己搭起来”
- 对平台能力的感知更完整，因为仓库、流水线、镜像、集群都在自己手里
它为什么后来不再适合作为主路线
- 更依赖本地网络和本地机器状态
- 镜像分发、外部访问和云端协同不够自然
- 当 Homelab 从高配本地转向低功耗收缩后，这套链路的维护成本变得更敏感
现在模式：云端协同 CI/CD
现在这条链路不再追求“全部本地化”，而是把更适合放到云端的职责拆出去，让交付边界更清楚，也让整套系统更符合当前的成本和网络条件。
这条链路里，我更关心的已经不是“功能能不能跑”，而是职责拆分是否合理：
GitHub负责代码托管和协作入口GitHub Actions负责 CI 和镜像构建GitHub Packages / Docker Hub负责镜像分发GitOps Repo负责承接部署版本Argo CD继续作为 CD 的执行面- 云端
Kubernetes负责承接更适合公网和协同环境的工作负载
变化点不只是换工具
很多人看到这里只会说“从 Jenkins 换成 GitHub Actions 了”，但对我来说，更重要的是这些边界变化：
- CI 从本地搬到了更自然的云端执行环境
- 镜像分发和集群部署不再强依赖家庭网络
- GitOps 的角色被保留了下来，说明我不是从流水线式交付退回“手动部署”
- 部署目标从本地集群逐步切到云端 K8s，更符合现在这套 Homelab 的分层思路
现在这套模式主要在验证什么
GitHub Actions不只是代替Jenkins，而是在验证云端 CI 是否能更稳定地承接构建和制品输出Registry和云端Kubernetes的组合，让镜像分发不再受家庭网络出口限制GitOps Repo继续承接版本声明，说明这条链路仍然保留“版本可追踪、部署可回放”的思路- 本地环境从“承担整条交付链路”转成“保留必要实验与基础能力”，这是一次架构职责重划，不只是迁移
两套模式怎么理解
| 维度 | 先前模式 | 现在模式 |
|---|---|---|
| 代码托管 | Gitea | GitHub |
| CI 执行 | Jenkins | GitHub Actions |
| 镜像管理 | Harbor + Trivy | GitHub Packages / Docker Hub |
| CD 方式 | Argo CD + 本地 GitOps 仓库 | Argo CD + 云端 GitOps 仓库 |
| 部署目标 | local.k8s | 云端 Kubernetes |
| 核心目标 | 在本地闭环跑通整条链路 | 让交付边界更适合云端协同 |
这页真正想说明什么
我更希望这页最后留下来的印象，不是“我会用 Jenkins”或者“我会写 GitHub Actions”，而是这些更底层的能力：
- 我能从零搭一条完整的交付闭环
- 我知道构建面、镜像面、部署面应该怎么拆
- 我能把 GitOps 放进真实交付链路，而不是只把它当成演示工具
- 当硬件、网络和维护成本变化时，我能重构链路，而不是只会沿用原来的方案
把这两套模式放在一起看，更重要的其实不是工具名变了，而是我确实在 Homelab 里把一条完整的 CI/CD 链路搭起来过，也在现实约束变化之后把它重新拆过、迁过、重构过。