Day 59 / 共 68 天 · 阶段 11 部署
CI/CD & IaC:让机器替你跑测试和部署
前两天你学会了打镜像(Docker)和编排容器(K8s)。可每次改完代码都要手动「跑测试 → 打镜像 → 推仓库 → apply 到 K8s」,一步错就翻车,还费时。今天学 CI/CD:用 GitHub Actions 把这条路自动化——你只管 git push,机器自动测试、构建、部署;再学 IaC(基础设施即代码) 和 Terraform,把「云上要建哪些机器/数据库」也写成代码、一键拉起。学完你就有了「专业开发的自动化流水线」;明天(Day 60)俯瞰云平台,看这些流水线最终把 Agent 部到哪里。
📍 你在阶段 11(部署 D57-61)的位置
D57 Docker→
D58 K8s 基础→
D59 CI/CD&IaC→
D60 云上部署→
D61 AI 网关
💡 用一个类比兜住今天(今天全程沿用「自动化工厂流水线」的世界观)
交付软件 = 经营一条工厂流水线。CI(持续集成) = 上料后的自动质检工位(每次进新零件都自动检验合不合格,不合格当场拦下);CD(持续交付/部署) = 质检通过后的自动装配+发货工位(打包、送到门店上架);GitHub Actions = 这条流水线的传送带+机械臂(你 push 代码就自动启动);IaC / Terraform = 建厂蓝图(厂房、水电、机器怎么建,写成图纸,照图一键盖厂,不用工人凭记忆手搭)。今天你从「手工作坊」升级成「自动化车间」。
L01
CI/CD 是什么:手工部署的痛
🤔 痛点手动部署的经典事故:忘了跑测试就上线、打错镜像 tag、部署步骤记错顺序、周五下班前手滑把生产搞挂。人是会累会忘的,重复的手工活迟早出事。
💡 本质CI/CD = 把「测试→构建→部署」这套重复动作交给机器自动做,每次代码一变就自动跑,标准、可靠、可重复。
CI(Continuous Integration,持续集成):每次提交代码,自动跑测试和检查,坏的当场拦住,不让烂代码合进主干。
CD(Continuous Delivery/Deployment,持续交付/部署):测试通过后,自动打镜像、推仓库、部署到环境。就像流水线上「先质检、再装配发货」,一气呵成。
CI(Continuous Integration,持续集成):每次提交代码,自动跑测试和检查,坏的当场拦住,不让烂代码合进主干。
CD(Continuous Delivery/Deployment,持续交付/部署):测试通过后,自动打镜像、推仓库、部署到环境。就像流水线上「先质检、再装配发货」,一气呵成。
图注:绿色是你唯一动手的一步,后面全自动。任一环节失败,流水线停下并通知你——绝不让坏代码溜到线上。
👶 「持续交付」和「持续部署」都叫 CD,区别是啥?就差一道人工闸门:持续交付——自动做到「随时可发布」,但真正上线前要人点一下「确认发布」;持续部署——连这一下都省了,测试过就直接自动上线。新手项目/关键系统常用「持续交付」(留个人工确认更稳),成熟团队才敢全自动部署。
L02
GitHub Actions:流水线的传送带
🤔 痛点道理懂了,可这条流水线用什么搭?难道自己写一堆脚本+定时任务?太重了。
💡 本质GitHub Actions = GitHub 自带的免费流水线工具:在仓库里放一个 YAML 文件,声明「当发生某事件(如 push),就在一台临时机器上按步骤跑这些命令」。不用自己养服务器。核心三个词:workflow(整条流水线)、job(一个阶段,如「测试」)、step(一个具体动作,如「跑 pytest」)。像给传送带编程:什么时候启动、经过哪几个工位、每工位干啥。
# .github/workflows/ci.yml —— 放在仓库这个固定路径,GitHub 自动识别
name: CI # 这条流水线的名字
on: # ★ 触发条件:什么时候启动
push:
branches: [ main ] # 有人 push 到 main 分支时自动跑
jobs:
test: # 一个 job(阶段),名叫 test
runs-on: ubuntu-latest # 在一台临时的 Ubuntu 机器上跑(GitHub 免费提供)
steps: # 这个阶段的一步步动作
- uses: actions/checkout@v4 # step1:把代码拉下来
- uses: actions/setup-python@v5 # step2:装好 Python 环境
with: { python-version: "3.11" }
- run: pip install -r requirements.txt # step3:装依赖(Day05 的老朋友)
- run: pytest # step4:跑测试
路径 .github/workflows/ 是固定约定,放这里 GitHub 才会自动跑。uses 是「用别人写好的现成动作」(如 checkout、setup-python),run 是「执行一条 shell 命令」。这两个词认得就能读懂九成 workflow。
📝 举个例子:push 后去哪看结果
push 之后,打开 GitHub 仓库的 Actions 标签页,能看到这条流水线正在跑,每个 step 是绿勾还是红叉一目了然。红叉点进去看日志就知道哪步挂了。PR 页面也会显示 ✅/❌——没过 CI 的 PR,团队约定不许合并(这正好接上 Day 52 学的「不达标拦合并」)。
L03
CI 环节:自动质检那道工位
🤔 痛点光跑单元测试还不够。对 Agent 这种项目,「代码语法对」不代表「Agent 答得对」。质检该检哪些?
💡 本质CI 这道质检工位可以叠加多重检查,越靠前拦得越早越省事:代码风格 → 单元测试 → (Agent 项目特有)评测集回归。回忆 Day 49~52:你攒的「golden set(标准问答集)」正好可以塞进 CI——每次改 prompt/换模型,自动跑一遍评测,分数掉了就拦住,防止「悄悄改坏了」。
| 质检项 | 检什么 | 对应课 |
|---|---|---|
| Lint 代码风格 | 格式/明显低级错(如未用变量) | — |
| 单元测试 pytest | 函数逻辑对不对 | — |
| 评测集回归 | Agent 答对率有没有下滑 | Day 49~52 |
| 安全扫描 | 依赖有没有已知漏洞、有没有硬编码密钥 | Day 20/54 |
👶 小白:跑评测要调真模型花钱,每次 push 都跑不会很贵吗?
👨🏫 老师:好问题,这正是 Day 56 成本意识的延续!常见做法:① 评测集用「小而精」的几十条核心用例,不用全量;② 分层——每次 push 只跑快而便宜的单元测试,较贵的评测集回归只在合并到 main 前或每晚定时跑一次(on: schedule);③ 评测里能用规则判的就别调模型。把「快而便宜的检查」放前面挡掉大部分问题,「慢而贵的检查」放后面兜底——又快又省,这是 CI 设计的通用智慧。
L04
CD 环节:自动装配 + 发货
🤔 痛点测试过了,接下来「打镜像 → 推仓库 → 部署到 K8s」这几步,怎么也让机器自动干?而且这里要用到密钥(登录镜像仓库、连 K8s),难道写进 YAML?
💡 本质CD 就是在 CI 后面接上「构建 + 部署」的 job。关键规矩:① 只有测试通过(
needs: test)才继续;② 一切密钥用 GitHub 的 Secrets 保管(在仓库设置里存,YAML 里用 ${{ secrets.XXX }} 引用,绝不明文)。就像流水线:质检不合格的货绝不放行到装配线;仓库钥匙锁在保险柜,机械臂用时才取。 build-deploy:
needs: test # ★ 必须等 test 这个 job 成功,才轮到我
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: 登录镜像仓库
run: echo "${{ secrets.REGISTRY_TOKEN }}" | docker login -u me --password-stdin
# └ 从保险柜(Secrets)取钥匙,不写明文
- name: 构建并推送镜像
run: |
docker build -t my-agent:${{ github.sha }} . # 用提交号当版本号,唯一可追溯
docker push my-agent:${{ github.sha }}
- name: 部署到 K8s
run: kubectl set image deploy/my-agent agent=my-agent:${{ github.sha }}
# └ 让 K8s 把 Deployment 换成新镜像 → 触发昨天学的滚动升级
👶 为什么用
github.sha(提交号)当镜像版本,不用 latest?因为 latest 会不停被覆盖,你根本说不清线上跑的到底是哪次代码——出了 bug 想回滚都找不到对应版本。用提交号(每次 push 唯一)当 tag,线上跑的镜像和某一行代码严丝合缝对上,回滚(kubectl rollout undo)、排查都有据可查。这是「可追溯」的基本功。L05
IaC & Terraform:把「建厂」也写成代码
🤔 痛点应用会自动部署了,可它跑在哪?云上的服务器、数据库、网络这些「地基」,难道还在网页控制台里手点鼠标一个个建?点错一个配置、换个环境要重来、团队没人说得清「线上到底建了哪些东西」。
💡 本质IaC(Infrastructure as Code,基础设施即代码)= 把「要建哪些云资源」写成代码文件,而不是手点控制台。Terraform 是最主流的 IaC 工具:你写一份声明(我要 1 台服务器 + 1 个数据库 + 1 个 K8s 集群),它自动去云上建好;改代码再跑,它算出差异只改变化的部分。像「建厂蓝图」:照图施工,可复制、可审查、可版本管理——想再开一个一模一样的测试环境?复制蓝图跑一遍就行。
# main.tf(Terraform 用的是 HCL 语言,长得像配置,读起来很直白)
# 声明:我要在云上建一台虚拟服务器
resource "server" "agent_host" { # resource=一个资源, 类型=server, 起名 agent_host
size = "2core-4gb" # 规格:2 核 4G
image = "ubuntu-22.04" # 系统镜像
region = "singapore" # 部署region(示意)
}
# 声明:给它配一个数据库
resource "database" "agent_db" {
engine = "postgres"
size = "small"
}
# 上面只是「想要的状态」。跑 terraform apply,它就去云上真建出来。
上面是示意语法(真实的 Terraform 资源名由各云厂商 provider 决定,如
aws_instance),别照抄。今天记住这个理念就够:基础设施 = 代码 = 能进 git、能 review、能复现。它和 CI/CD 是绝配——CI/CD 管「应用」,IaC 管「应用跑的地基」,两者都是「一切皆代码、机器自动执行」。📝 举个例子:IaC 救命的一天
线上机房整个挂了。有 IaC 的团队:
terraform apply 在另一个地区把全套基础设施照蓝图重建,半小时恢复。没 IaC 的团队:翻聊天记录回忆「当初到底建了啥、怎么配的」,折腾一整天还漏东漏西。「基础设施写成代码」不是炫技,是灾难恢复和团队协作的保命符。L06
串成完整流水线:一次 push 走完全程
🤔 痛点CI、CD、IaC 各自懂了,它们在真实项目里怎么配合成一条完整的自动化链条?
💡 本质把今天学的拼起来,就是现代软件交付的标准姿势:IaC 先把地基(K8s 集群等)建好(不常变) → 之后每次改代码 push,GitHub Actions 自动跑 CI(测试+评测) → 通过后 CD 打镜像、部署到那套地基上 → K8s 滚动升级不停机 → Day55 的可观测盯着新版本健康度,不对就一键回滚。整条线,人只在写代码和「确认发布」两处出现。
图注:这张图几乎串起了整个部署篇——面试时能照它讲一遍「你们怎么交付一个 Agent」,就很有说服力。
📝 举个例子:写进简历的一句话
「搭建了基于 GitHub Actions 的 CI/CD 流水线:push 自动跑单测 + 评测集回归,通过后按提交号打 Docker 镜像并滚动部署到 K8s,配合监控实现分钟级发布与一键回滚。」这一句话,把 Day 57~59 全考点都体现了——含金量极高。
L07
今日小结 + 动手 10 分钟
🧠 今天你应该能回答
- CI 和 CD 分别解决什么?「持续交付」和「持续部署」差在哪?
- GitHub Actions 的 workflow / job / step 是什么?文件放哪个路径?
- CI 里对 Agent 项目该加什么特殊质检?(评测集回归)怎么控制它的成本?
- CD 里密钥怎么管?为什么镜像 tag 用提交号而不是 latest?
- IaC 是什么理念?Terraform 干嘛的?它救了哪些命?
- 把 IaC + CI/CD + K8s + 可观测串起来,一次发布是怎么走完的?
✋ 动手 10 分钟:给一个仓库加一条最小 CI
找一个你自己的 Python 项目(哪怕只有一个函数 + 一个测试),加 CI 体验「push 后机器自动跑测试」:
# 1) 在项目里建目录和文件:.github/workflows/ci.yml
# 内容直接用本页 L02 的那段 YAML(改成你的项目即可)
# 2) 提交并推上去
git add .github/workflows/ci.yml
git commit -m "add CI pipeline"
git push
# 3) 打开 GitHub 仓库 → 点顶部「Actions」标签
# 你会看到这条流水线正在自动跑,每个 step 有 ✅ / ❌
# 故意写个失败的测试再 push 一次,看它变红并通知你——体会「自动质检拦截」
没有现成项目?用 Day05 建的小类项目,配一个 test_demo.py(里面写一句 assert 1+1==2),照上面走一遍即可。亲手让绿勾亮起来的那一刻,你就真正理解 CI 了。
明日预告 · Day 60:你已经会「打包 + 编排 + 自动化交付」了。可这些最终跑在哪片云上?明天做一次云上部署概览:俯瞰主流托管 LLM/Agent 的云平台——AWS Bedrock、GCP Vertex AI、Azure ML、SageMaker,讲清它们各自定位、怎么选型,让你面试聊到「上云」时心里有张全景图。