如果你还在用 FTP 拖拽文件、用 WinSCP 连 SSH 改配置、或者每次改完代码都要手动打包压缩再上传，那么这篇文章就是为你准备的。

2026 年的开发早已告别“人肉运维”。不管是独立开发者、小团队还是企业项目，CI/CD（持续集成/持续部署） 已经从“大厂标配”变成了“基础生存技能”。很多人一听到 CI/CD 就想到复杂的 Jenkins 集群、K8s 调度、海量 YAML 配置，其实那是被过度包装了。对个人和中小型项目来说，CI/CD 的核心只有三句话：代码提交后自动测试 → 测试通过自动打包 → 打包成功自动推上服务器。 全程不需要你手动敲命令，更不需要半夜爬起来发版。

今天这篇不扯架构理论，不堆砌冷门工具。我会用最直白的大白话+可复制的配置，带你从 0 到 1 搭一套稳定、安全、轻量级的自动化部署流水线。全文较长，建议配合你的代码仓库边看边配，每一步都能直接落地。

一、先拆词：CI/CD 到底是什么？别被缩写吓住

把技术术语翻译成日常场景，理解起来就毫无门槛：

• CI（Continuous Integration，持续集成）：“自动质检员”。每次你 push 代码，系统自动拉下来跑测试、查语法、扫安全漏洞。不合格直接打回，不让烂代码混进主线。
• CD（Continuous Deployment/Delivery，持续部署/交付）：“自动搬运工”。质检通过后，自动打包成可运行文件，通过安全通道传到你服务器上，并重启服务。你只管写代码，上线它帮你干。
• Pipeline（流水线）：把 CI 和 CD 串起来的一条“自动化生产线”。比如：拉代码 → 装依赖 → 跑测试 → 打包 → 传服务器 → 重启服务。每一步叫一个 Job。
• Runner（运行器）：干活的“工人”。可以是 GitHub 官方提供的免费虚拟机，也可以是你自己闲置的旧电脑或轻量服务器。

核心逻辑就一句：用配置文件告诉平台“当你收到代码更新时，按什么顺序执行哪些命令”。剩下的交给机器，稳定、可追溯、零人为失误。

二、你的第一条流水线：30 分钟跑通 GitHub Actions

2026 年最轻量、免安装、开箱即用的方案是 GitHub Actions。它直接在仓库里跑，不需要额外买服务器装 Jenkins。以下以常见的 Node.js / 前端项目为例（Python、Go、PHP 逻辑完全一致，只需替换构建命令）。

1. 创建配置文件

在你的项目根目录新建文件夹：，在里面建一个文件：（名字随意，但后缀必须是 ）。

2. 粘贴基础配置

name: 自动构建与部署 on: push: branches: [ main ] # 仅当推送到 main 分支时触发 jobs: build-and-deploy: runs-on: ubuntu-latest steps: # 1. 拉取代码 – name: 检出代码 uses: actions/checkout@v4 # 2. 配置 Node 环境（按需替换版本） – name: 设置 Node.js uses: actions/setup-node@v4 with: node-version: ’20’ # 3. 安装依赖 & 打包 – name: 安装依赖并构建 run: | npm ci npm run build # 4. 部署到服务器（通过 SSH） – name: 同步文件到服务器 uses: appleboy/ssh-action@v1.0.0 with: host: ${{ secrets.SERVER_HOST }} username: ${{ secrets.SERVER_USER }} key: ${{ secrets.SSH_PRIVATE_KEY }} script: | cd /var/www/myapp rm -rf dist cp -r /home/runner/work/repo/repo/dist ./ pm2 restart myapp # 如果是纯静态站，可替换为 nginx -s reload

• ：只在推送到 时触发，避免测试分支频繁上线。
• ：指定 GitHub 提供的 Ubuntu 虚拟机运行。
• ：比 更快、更确定，严格按 安装。
• ：官方社区维护的 SSH 部署插件，安全、稳定、支持密码/密钥。

三、服务器准备：让流水线能“安全敲门”

流水线配好了，但服务器还不知道谁来访问。2026 年标准做法是SSH 密钥认证，彻底告别密码登录和明文传输。

1. 本地生成 SSH 密钥（仅用于部署）

ssh-keygen -t ed25519 -C “ci-deploy-2026” -f ~/.ssh/ci_deploy

一路回车，不设置密码。你会得到两个文件：（私钥）和 （公钥）。

2. 把公钥放到服务器

# 本地执行 ssh-copy-id -i ~/.ssh/ci_deploy.pub 你的用户名@服务器IP # 测试是否免密登录成功 ssh -i ~/.ssh/ci_deploy 你的用户名@服务器IP
能直接进服务器，说明配置成功。

3. 把私钥和服务器信息存入 GitHub Secrets

进入你的 GitHub 仓库 → Settings → Secrets and variables → Actions → New repository secret：

• ：你的服务器公网 IP 或域名
• ：SSH 登录用户名（通常是 或 ）
• ：完整粘贴 私钥内容（包含 行）

安全提示：GitHub 的 Secrets 是加密存储的，流水线运行时会自动注入环境变量，日志中只会显示 ，不会泄露。

四、部署脚本优化：别只靠“复制粘贴”，要写得健壮

上面的 部分比较原始。真实生产环境建议把部署逻辑抽离成服务器上的脚本，流水线只负责“调用”。

在服务器创建：

#!/bin/bash set -e # 遇到错误立即退出，防止半残状态 APP_DIR=”/var/www/myapp” BACKUP_DIR=”/backups/myapp/$(date +%Y%m%d_%H%M%S)” echo “📦 开始部署…” mkdir -p $BACKUP_DIR # 1. 备份当前版本（防翻车） if [ -d “$APP_DIR/dist” ]; then cp -r $APP_DIR/dist $BACKUP_DIR/ echo “✅ 已备份至 $BACKUP_DIR” fi # 2. 清理旧文件 & 同步新文件 rm -rf $APP_DIR/dist # 假设流水线通过 rsync 推送到了 /tmp/new_dist if [ -d “/tmp/new_dist” ]; then mv /tmp/new_dist $APP_DIR/dist fi # 3. 设置权限（Web 服务器需要可读） chown -R www-data:www-data $APP_DIR chmod -R 755 $APP_DIR # 4. 重启服务 systemctl reload nginx # 或 pm2 restart myapp echo “🚀 部署完成！访问 https://你的域名 查看效果”

给脚本执行权限：

流水线中的 改为：。这样后续加灰度发布、数据库迁移、缓存清理，都不用改 GitHub 配置，全在服务器脚本里维护。

五、常见翻车现场与排错指南

自动化不是魔法，第一次跑大概率会报错。别慌，按下面清单对号入座：

1. 报错：Permission denied (publickey)

SSH 密钥没配对。检查：
① 私钥是否完整粘贴到 Secrets（换行符不能少）
② 公钥是否写入服务器
③ 服务器 中 是否开启

2. 报错：npm ci 失败 / 依赖装不上

GitHub Actions 的 Ubuntu 环境是干净的，没有全局缓存。确保：
① 仓库里有 或
② 不要依赖本地全局安装的 CLI 工具（如未声明在 ）

3. 部署成功但网站 403/404

通常是路径或权限问题：
① Nginx 的 是否指向正确的 目录
② 文件所有者是否是 或 用户
③ 检查 ，日志会精确到哪一行拒绝访问

4. 每次部署都超时

GitHub 免费额度有 10 分钟/Job 限制。优化：
① 用 替代
② 跳过测试或分阶段运行（测试用 ，部署用轻量 Runner）
③ 考虑使用自托管 Runner（见下文）

六、2026 年 CI/CD 进阶实践：让流水线更聪明

• 环境隔离（Environments）：在 GitHub 设置中创建 和 环境，配置不同的 Secrets。流水线里用 自动切换变量，一套配置跑多套环境。
• 失败自动回滚：在部署脚本开头记录当前 Git commit hash，如果新版本健康检查失败（如 ），自动切回上一次备份目录。
• 自托管 Runner：如果你的项目依赖庞大或网络受限，可以在自己的轻量服务器装 。跑得快、不耗云额度、内网直连，适合私有化部署。
• 安全扫描前置：集成 自动提依赖更新 PR；在流水线加 或 扫描容器/依赖漏洞。安全不是上线后才考虑的事，是流水线的第一道门。
• 通知机制：在 末尾加一个飞书/钉钉/Slack Webhook 请求，部署成功或失败直接推消息到手机。不用盯着网页看 Logs。

七、给 2026 开发者的 4 条 CI/CD 心法

• 先跑通，再优化。 别一上来就搞多环境、灰度发布、数据库迁移脚本。先让“push 代码 → 自动上线”这条最短路径跑起来，信心建立后再迭代。
• 流水线是代码，要像对待业务代码一样对待它。 文件提交到版本控制，改配置走 PR，加注释说明为什么这么配。三个月后你会感谢现在的自己。
• 日志是最好的老师。 部署失败不要盲目改配置。点进 Actions 面板，展开每个 step 的日志，搜索 、、。90% 的问题日志里写得明明白白。
• 自动化不是替代人，是释放人。 省下来的时间别用来摸鱼，用来写更好的测试、优化架构、陪家人。技术最终是为了让人活得更轻松，而不是更焦虑。

结语：今天推一次代码，明天少加一次班

CI/CD 从来不是“等做大项目才用”的奢侈品，而是“越早用越早受益”的基础设施。当你第一次看到手机弹出“部署成功”，打开浏览器发现最新改动已经安静地躺在生产环境时，那种“原来我可以这么从容”的掌控感，会让你彻底回不去手动上传的时代。

如果你在配置过程中遇到具体的报错日志、YAML 缩进问题、或者 SSH 权限卡住，欢迎在评论区贴出完整错误片段（注意打码 IP 和密钥）。我会用“定位原因 + 给出可执行修复命令”的方式为你逐一拆解。

愿你的每一次 push，都能安全、快速、静默地抵达用户面前。

Content retrieved from: https://www.qiandan.net/archives/2370.html.