CI/CD：你点一下鼠标，代码就自动上线了！

想象一下你开发一个新功能（比如一个炫酷的按钮）的完整流程：

1. 写代码：在你本地电脑上 git add ., git commit -m "feat: 新增炫酷按钮"。
2. 传代码：git push 到 GitHub（或GitLab等）上。
3. 测试代码：自己手动跑一下测试，看看有没有bug。
4. 打包代码：用 Webpack/Vite 打包成最终的JS、CSS文件。
5. 部署代码：用FTP或者SCP啥的，手动把打包好的文件拖到服务器上。
6. 重启服务：可能还要在服务器上敲命令重启一下Nginx。

烦不烦？累不累？容易出错不？

CI/CD 就是为了把上面第3步之后所有这些“手动、重复、容易出错”的活儿，全都变成自动化的！

CI/CD 是啥？其实就是两个概念拼起来的

第一部分：CI（持续集成）

• 白话翻译：“自动测试和打包”
• 干啥用的： 保证你提交的代码没问题，并且能变成可以上线的产品。

它怎么工作的？（就像一个自动化的质检员）

1. 只要你一 git push，CI系统（比如GitHub Actions）立马就被激活了。
2. 它会在一个干净的“工厂”（服务器） 里，拉取你最新的代码。
3. 然后在这个工厂里，执行你预设好的命令：

• npm install （安装依赖）
• npm run test （运行测试用例，看看你的新按钮有没有把旧功能搞坏）
• npm run build （打包，生成 dist 目录）

CI的核心思想： 频繁地集成代码，尽早发现错误，避免等到要上线了才发现一堆冲突和BUG。

第二部分：CD（持续部署/交付）

• 白话翻译：“自动发布到线上”
• 干啥用的： 把CI阶段打包好的、没问题的产品，自动放到服务器上，让用户能访问到。

它怎么工作的？（就像一个自动化的快递小哥）

CI阶段成功后，CD系统就接着干活了：

1. 它拿起CI阶段打包好的 dist 文件夹。
2. 它通过SSH等安全方式，连接到你们的线上服务器。
3. 它把 dist 文件夹里的所有文件，“扔”到服务器上Nginx配置好的网站目录里（比如 /usr/share/nginx/html/）。
4. （可选）它可能还会执行一些命令，比如重启Nginx服务，让新代码生效。

然后...就没了！

你的用户现在刷新浏览器，就能看到你那个炫酷的新按钮了。

CD的两个小区别：

• 持续交付：快递小哥把产品打包好，放在门口，等你说一句“发货”，他才发出去。
• 持续部署：快递小哥连等都不等，产品质检一通过，自动就发出去了。这是更极致的自动化。

用一个前端例子串起来整个流程

假设你用 Vue 写了一个项目，用了 GitHub Actions 做 CI/CD。

1. 创建CI/CD配置文件 (.github/workflows/deploy.yml)

在你的项目根目录创建这个文件夹和文件，这是定义自动化流程的“剧本”。

# .github/workflows/deploy.yml
name:DeploytoGitHubPages# 这个工作流的名字
# 触发条件：当代码被推送到 main 分支时，自动运行这个工作流
on:
push:
branches:["main"]
# 授予这个工作流的权限，允许它写入仓库内容（比如推送到gh-pages分支）
permissions:
contents:write
#  jobs 定义了这个工作流要执行的一系列任务
jobs:
# 一个名为 build-and-deploy 的任务
build-and-deploy:
# 这个任务运行在最新的 Ubuntu 系统上
runs-on:ubuntu-latest
# 步骤集合
steps:
# 步骤1: 拉取代码（GitHub Actions 已经帮我们准备好了这个动作）
-name:Checkoutcode
uses:actions/checkout@v4
# 步骤2: 设置 Node.js 环境
-name:SetupNode
uses:actions/setup-node@v4
with:
node-version:'18'# 指定你项目使用的Node版本
cache:'npm'
# 步骤3: 安装依赖 (CI 环节)
-name:Installdependencies
run:npmci# 使用ci命令比install更严格，适合自动化环境
# 步骤4: 打包构建 (CI 环节)
-name:Buildproject
run:npmrunbuild# 这会运行你package.json里的build脚本，生成dist文件夹
# 步骤5: 部署到 GitHub Pages (CD 环节)
-name:DeploytoGitHubPages
uses:peaceiris/actions-gh-pages@v3# 使用一个现成的部署Action
with:
# 下面是这个Action需要的参数
github_token:${{secrets.GITHUB_TOKEN}}# GitHub自动提供的令牌，无需自己设置
publish_dir:./dist# 告诉Action，你要发布的是哪个文件夹

2. 你 push 代码

你修了个bug，然后 git push origin main。

3. 自动化流程在背后运行

1. GitHub Actions 检测到 main 分支有推送，自动开始运行 deploy.yml 这个“剧本”。
2. 它在虚拟服务器里，按顺序执行 npm ci -> npm run build。
3. 如果这两步任何一步失败（比如测试没通过或打包出错），流程会立刻中断，GitHub会给你发邮件告警。
4. 如果成功，peaceiris/actions-gh-pages 这个工具会把你生成的 dist 文件夹里的所有内容，推送到你仓库的 gh-pages 分支。

4. 上线成功

因为 GitHub Pages 的设置就是托管 gh-pages 分支的内容。所以几分钟后，你的网站就自动更新了！

对你来说，你只做了 git push，后面的所有步骤全是自动的。这就是CI/CD的魅力！

如果是部署到自己的服务器呢？

配置文件会有点不一样，核心是使用 ssh-action 来连接你的服务器并执行命令。

# ... 前面的部分（ checkout, setup-node, install, build ）都一样 ...
# 部署步骤换成这样：
-name:DeploytoServerviaSSH
uses:appleboy/[email protected]
with:
host:${{secrets.SERVER_HOST}}# 你的服务器IP
username:${{secrets.SERVER_USER}}# 登录用户名
key:${{secrets.SSH_PRIVATE_KEY}}# SSH私钥
# 这一串命令的意思是：清空服务器上的旧网站文件，把新的dist文件夹传上去
script:|
            rm -rf /usr/share/nginx/html/*
            scp -r ./dist/* your_username@your_server_ip:/usr/share/nginx/html/
            sudo systemctl restart nginx # 重启nginx

注意：这里的 secrets.SERVER_HOST, secrets.SSH_PRIVATE_KEY 等都需要你在GitHub仓库的 Settings -> Secrets 里面手动配置好，代码里直接引用，非常安全。

总结一下CI/CD的好处（说人话版）

1. 省事！ 不用再手动打包上传了，解放双手。
2. 靠谱！ 自动化流程不会像人一样犯困、手滑，减少人为失误。
3. 快速！ 可以非常频繁地发布新版本，快速响应用户需求。
4. 透明！ 每一步都能看到日志，出了问题容易定位。

所以，CI/CD不是什么高大上、遥不可及的东西。它就是一套自动化流水线，你只要定义好规则（写一个YAML配置文件），以后你唯一的任务就是安心写代码和 git push，剩下的，交给流水线就好！

这下是不是彻底懂了？