用华为云搭的自动部署小流水线

以前我部署一个小项目，流程全靠手和记忆：本地改完代码，打包，打开终端，用 scp 传到服务器，再 ssh 上去解压、重启服务。有一次临睡前改了个小样式，迷迷糊糊传错了文件夹，网站直接白屏，第二天早上才发现。那一刻我就想，这事不能再靠手了，得让机器替我记住步骤。后来我把这套流程搬到了华为云的弹性云服务器 ECS 上，又接上了 GitHub Actions，做了一条很小的自动部署流水线。从那以后，我的工作只剩下一件事：把代码推到仓库，剩下的交给流水线。

说白了，自动部署就是给代码装一条传送带。你推一次代码，传送带就自动跑一圈：先拉取最新代码，再安装依赖、跑一遍构建，构建通过了，才把产物送到服务器上，重启服务。如果中间哪一步失败，传送带就停下来，旧版本还好好地跑着，不会把半成品推给访客。对我这种一个人写 side project 的学生来说，它最大的好处不是显得专业，而是省心。以前每次上线都要默念一遍步骤，生怕漏掉哪一步；现在步骤写进了配置文件，机器不会困、不会手抖，也不会在半夜把文件传错地方。

准备工作其实很简单。我先把项目放进了 GitHub 仓库，分支也很简单：main 是线上版本，平时开发用 dev 分支，改好了再合并。这样做的好处是，流水线只监听 main 分支的推送，开发时的半成品不会误触上线。服务器就是之前开好的那台华为云 ECS，上面装了 Nginx，跑一个很小的个人主页和几个课程作业演示页。部署用的目录单独划出来，不跟系统目录混在一起，权限也只给部署账号，不用 root 直接跑脚本，这一点是被前辈提醒后才改过来的，图个安心。密钥的处理我也特意小心了一次：服务器地址、账号和私钥都存在 GitHub 仓库的 Secrets 里，配置文件里只写变量名，不写真实值。这样就算以后把仓库公开给同学看，也不会把服务器钥匙一起公开。

我的流水线其实只有四步，写在一个 YAML 文件里，看起来有点像菜谱。第一步，检出代码：流水线先把 main 分支的最新代码拉下来，保证它跟我本地推上去的版本一模一样。第二步，安装依赖并构建：跑 npm install 和 npm run build，生成可以直接放到服务器上的静态文件。如果这里报错，流程立刻停下，我会收到提醒，而不是让错误的代码继续往下走。第三步，同步到服务器：构建通过后，用 rsync 只把变化的文件传过去，而不是每次全量覆盖，这样传得快，出错面也小。第四步，重启并自检：传完后在服务器上重启 Nginx，然后流水线去访问一次首页，返回 200 才算成功；如果首页打不开，就立刻报警，我再手动回滚。整条流程跑下来大概两三分钟，比我以前手动操作还快，更重要的是，每一步都有日志，出了问题能翻到具体是哪一步卡住的。

当然，第一次跑通之前也翻过车。最典型的一次是构建成功了，页面却还是旧的。查了半天，才发现是浏览器缓存和 Nginx 缓存叠加，文件其实已经换了，我看到的还是旧版本。后来我在部署脚本里加了一步：给静态资源文件名带上构建生成的哈希，旧文件自然失效，问题就消失了。还有一次是依赖装不上，原因是服务器和本地的 Node 版本不一致。解决办法也很土：把 Node 版本写进配置文件和 README，本地、流水线、服务器用同一个大版本，环境不一致的坑就少了很多。