从 AI 开发者空间到 CodeArts：一个人也能跑通的「提交即上线」部署链路

说明：原「开发者空间」的云主机将在 10 月 30 日前陆续下线，本文按新的 AI 开发者空间 + CodeArts 来写，步骤可直接复现。

一、为什么是这条链路

一个人做小项目，最费时间的往往不是写代码，而是「本地跑得好好的，上线又出问题」：环境不一致、构建命令记不住、部署靠手工 scp、出问题不知道回滚到哪一版。

CodeArts 把仓库、构建、部署、流水线放在同一个项目里，配上 AI 开发者空间的云端 IDE，可以做到一件事：改完代码 git push，两分钟后站点就是新的。这篇就把这条链路从头搭一遍。

二、整体链路

本地 / 云端 IDE（AI 开发者空间）
        │  git push
        ▼
   CodeArts Repo  ──触发──▶  CodeArts Pipeline
                                ├─ 阶段一：构建（CodeArts Build）
                                └─ 阶段二：部署（CodeArts Deploy → ECS）
                                          │
                                          ▼
                                   Nginx 静态站点

三、准备工作

1. 一台 ECS，2C4G 起步即可，装好 Nginx，安全组放行 22 和 80；
2. 在 CodeArts 里新建一个项目，仓库、构建、部署、流水线都建在同一个项目下，权限和产物管理会省很多事；
3. 一个能在浏览器里打开的仓库地址——如果不想在本地装 Node，就用 AI 开发者空间开一个云端 IDE，直接在里面 clone、改、提交。

四、第一步：代码进 Repo

目录结构保持简单：

my-site/
├── src/
├── package.json
├── deploy.sh
└── .gitignore

.gitignore 里一定要排除 node_modules 和 dist，构建产物交给流水线生成，不要提交进仓库，否则每次 diff 都是一堆噪音。

五、第二步：构建任务

CodeArts Build 里新建构建任务，选 Node.js 类模板，构建命令两步就够：

npm ci
npm run build

关键是产物目录要显式配置：把 dist 作为构建产物归档（或推送到制品仓库）。很多人第一次配流水线失败，就是因为构建成功了，但部署阶段拿不到包——产物路径没配，等于白构建。

六、第三步：部署脚本

部署阶段不要直接 scp 覆盖线上目录，用「版本目录 + 软链」的方式，回滚会非常轻松：

#!/usr/bin/env bash
set -euo pipefail

APP_DIR=/opt/my-site
STAMP=$(date +%Y%m%d%H%M%S)
REL_DIR="$APP_DIR/releases/$STAMP"

mkdir -p "$REL_DIR"
tar -xzf /tmp/artifact.tar.gz -C "$REL_DIR"

# 先检查配置，再切换
nginx -t

ln -sfn "$REL_DIR" "$APP_DIR/current"
nginx -s reload

# 只保留最近 5 个版本
ls -1dt "$APP_DIR"/releases/* | tail -n +6 | xargs -r rm -rf

要点有三个：set -euo pipefail 让任何一步失败就中断；nginx -t 在切换前校验配置；软链切换是原子操作，不会出现「删了一半、用户访问 404」的中间态。

七、第四步：串成流水线

在 CodeArts Pipeline 里新建流水线：

1. 代码源选 CodeArts Repo，分支选 main；
2. 触发器打开「代码提交触发」，这样 push 就会自动跑；
3. 阶段一挂上刚才的构建任务；
4. 阶段二用主机部署，把 ECS 加进主机组，按页面提示在 ECS 上执行一条安装命令装好 Agent，然后指定部署脚本和产物来源。

配完之后，整条链路就通了：提交 → 自动构建 → 自动部署 → 站点更新。

八、第五步：验证与回滚

部署完别只看流水线是绿的，做两个验证：

curl -I http://<你的EIP>          # 期望 200
ls -l /opt/my-site/current        # 确认软链指向新版本

回滚就更简单了——把软链指回上一个版本目录，再 reload 一次：

ln -sfn /opt/my-site/releases/<上一个版本> /opt/my-site/current
nginx -s reload

九、五个踩过的坑

1. 部署用户没权限：别用 root 跑部署，建一个 deploy 用户，只给它 /opt/my-site 的写权限；
2. 直接覆盖目录导致 404：一定要用版本目录 + 软链，否则解压过程中用户会看到半成品；
3. 构建产物路径对不上：Build 里归档的目录和 Deploy 里取的包必须是同一个，名字对不上就是「构建成功、部署失败」；
4. 主机显示离线：先看 Agent 状态，再查安全组 22 端口和密钥是否正确，顺序别反；
5. 首次 reload 失败：多半是 Nginx 配置语法问题，先 nginx -t 再 reload，不要在流水线里盲试。

十、小结

这套链路搭一次大概半小时，之后每次发版只需要一次 push。真正省下来的不是那几分钟操作时间，而是「上线前心里没底」这件事——版本目录在、软链在、回滚命令在，出问题时有确定的下一步。

配合 AI 开发者空间，连本地环境都可以省掉：浏览器打开就能改代码、提交流水线。对个人项目和小团队来说，这套组合的性价比很高。