从线上手改到可重复发布，我先补的不是 CI，而是事实来源

直接在生产环境里部署过项目的人，后面都会碰到一个很不体面的阶段：服务明明还活着，但你已经说不清它是怎么活着的。

代码可能在服务器上，配置可能改过多次，Nginx 规则也许手动动过，甚至连“上一版到底是什么”都没有一个明确答案。

这种状态下，最危险的不是 bug，而是你开始失去事实来源。

为什么我不把第一步放在 CI 上

很多建议会直接跳到：

• 建仓库
• 配 GitHub Actions
• 自动部署
• 自动回滚

这些都没错，但如果你连当前线上版本的来源都没重新整理出来，CI 只会把混乱自动化。

我更想先补的是一条简单但可靠的事实链：

1. 当前代码放在哪里。
2. 当前静态产物从哪里构建。
3. 当前 Nginx 配置以哪个文件为准。
4. 当前线上目录怎么回滚。

只有把这四件事说清楚，后面的自动化才不会变成另一层黑箱。

我这次先做了什么

这次主站改造里，最关键的工程动作其实不是写 Astro 页面，而是把“线上正在跑的内容”和“本地能重建出来的内容”重新对齐。

具体做法很朴素：

把主站和项目前端都拉回本地工作区

不再默认服务器目录才是唯一真实版本。

让构建产物成为发布单位

博客由 Astro 构建，项目前端由 Vite 构建，最后合并成一套静态目录发到服务器。

单独备份 Nginx 配置

入口规则和页面代码分开管理。这样哪怕内容站点有问题，至少还能快速回退代理规则。

先稳定 HTTPS 和路径规则

没有证书、没有固定入口时，任何“发布流程”都只是半成品。

所谓“事实来源”，本质上是你以后敢不敢继续改

很多时候人不是不会写代码，而是不敢改线上。

不敢改通常不是因为项目太复杂，而是因为下面这些问题没有答案：

• 我现在改的是不是唯一生效版本。
• 改完之后如果出问题，我靠什么回退。
• 两周之后我还能不能解释这次上线做了什么。

事实来源一旦稳定，很多操作反而会变简单。你会知道该改哪一份文件，该跑哪一个 build，该把产物同步到哪个目录。

一个够用的最小发布流程

对个人项目来说，我现在更认可下面这种顺序：

1. 内容或代码先在本地工作区收敛。
2. 由固定脚本构建出静态产物。
3. 产物同步到服务器 staging 目录。
4. 确认入口和证书状态正常。
5. 再把 staging 推到正式目录。

它不华丽，但足够回答“这次上线改了什么，能不能回退”。

结语

如果一个项目已经在生产环境里被直接改过很多次，补课的第一步不是追求完整流程，而是重新建立事实来源。

先让自己能够清楚地说出：

• 代码在哪。
• 构建怎么来。
• 入口怎么走。
• 回退靠什么。

等这些答案稳定下来，再去补仓库治理、自动部署和更细的环境分层，才是真正往前走，而不是换一种方式继续把混乱藏起来。