---
title: "03-DevOps"
created: 2026-04-13
tags:
  - 项目
aliases:
  - DevOps
---

# DevOps

> DevOps（开发 Development 与运维 Operations 的结合）
>
> 核心：CI/CD 流水线（Pipeline）

## 缘起

我发现一个有意思的事情

照我们现在的部署方式 好像只需要把变动的文件传上去 补一下依赖 重启一下就能更新到最新状态？ 而不需要重新打包做一堆繁琐的工作 那这样的话 是不是意味着 我本地写完项目 git push 然后服务器写一个检测到变化就git pull的脚本 可以实现本地改完 直接push 线上就改了 而无需手动打包运维？

你发现了一个非常本质且核心的运维思路！你所描述的“本地写完 `git push`，服务器收到通知就 `git pull` 并自动重启”——这就是现代软件工程里大名鼎鼎的 **CI/CD（持续集成 / 持续部署）** 或者称之为**自动化部署**的最初级形态！

针对你提到的这个想法，在这个项目里，需要分**后端**和**前端**两部分来看：

### 1. 对于后端（Python FastAPI）—— 完全可行，和你猜的一模一样
Python 是解释型语言，没有“编译打包”这个概念。所以你本地写完 `routers/match.py`，直接 Git 传上去。服务器上只要 `git pull` 把最新的 `.py` 覆盖掉，然后宝塔的 Python 管理器（或者使用 PM2/Supervisor）执行一个 **Restart 重启指令**，瞬间就全服更新了。你确实不需要做任何繁琐的工作！

### 2. 对于前端（Next.js）—— 差了一小步
如果你留意我们 `readme.md` 的第三节【前端部署】：
```markdown
1. 在你的**电脑本地**，在 `frontend` 目录下运行 `npm run build`，完成 Next.js 的生产编译。
2. 将打包的文件 `.next` 上传至服务器...
```
因为前端用了 TypeScript 和 React，浏览器看不懂它们，它**必须经过打包**压缩成纯粹的 HTML/JS/CSS（即生成的 `.next` 隐形文件夹）。
如果你只在服务器 `git pull` 更新了 `page.tsx` 代码并重启 PM2，页面是**不会变**的，因为线上跑的是 `.next` 里面的编译产物，甚至会因为代码不同步崩掉。除非你在服务器上跑的是类似于本地的 `npm run dev`，但这极为消耗服务器性能，绝对不能在生产环境用。

---

### 如何完美实现你的“终极偷懒”推测？

你的思路完全没问题，只需要在这个自动化脚本里**加半行打包命令**而已！

你可以在宝塔面板里安装一个叫 **【WebHook】**（免费插件）。把它配上你的 Github / Gitee 仓库，一旦你本地按下了 `git push`，Github 就会悄悄向服务器发送一个更新信号，触发服务器自动执行一段 Bash 脚本。这段脚本的内容大概是这样的：

```bash
# 1. 拉取你刚 push 的最新代码
git pull origin main

# 2. 【后端】：更新可能有变动的依赖，重启进程
cd api
pip install -r requirements.txt
# 假设你的项目在pm2叫 api-server，重启它
pm2 restart api-server

# 3. 【前端】：安装依赖，并在服务器端进行“打包”，随后重启
cd ../frontend
npm install
npm run build   # 核心点：让服务器帮你干打包的苦力活！
pm2 restart next-server
```

**这样带来的改变是什么？**
以前：本地改前端 -> 本地慢慢打包（卡电脑） -> 用 FTP 把 几十MB 的文件传到云服务器 -> 重启。
现在：本地爽快地敲代码 -> `git add .` -> `git commit` -> `git push` -> **关电脑，去喝咖啡。**
服务器会乖乖地自己拉代码、自己把 `.tsx` 打包成压缩包，自己重启。这就是所谓的**流水线（Pipeline）**部署。你的直觉非常准，很多项目组花几十万搭 DevOps 就是为了全自动化实现你脑子里的这个流程！

---

**组内导航**：⬅️ [[02-产品经理（PM）|产品经理（PM）]] | 🏠 [[00-DevOps与运维|00-DevOps与运维]] | ➡️ [[04-从手动部署到自动呼吸：一场改变世界的运维革命|从手动部署到自动呼吸：一场改变世界的运维革命]]