Node/Next.js在EC2上：手动部署到CI/CD的过渡方案问询

本人使用Node开发已有18个月，近6个月正逐步将现有WordPress网站迁移至NextJS。目前一直采用手动部署：登录生产EC2服务器，从GitHub拉取最新版本代码、构建，再执行pm2重启。尽管该流程在网上较为常见，但我始终觉得存在问题。

近期因需自定义第三方代码，主项目的package.json中包含如下内容：

{
  ...
  "dependencies": {
    ...
    "react-share": "file:../react-share/react-share-4.4.1.tgz",
    ...
  },
  ...
}

这意味着我需要在生产服务器拉取自定义的react-share代码、构建，修改该依赖路径后重新构建主项目。此外，我使用Prisma，每次部署前需执行npx prisma generate生成客户端。这让我觉得当前流程漏洞百出。

我认为完整CI/CD环境对仅个人开发、单EC2实例（搭配AWS CloudFront）的场景来说过于冗余，但又希望为未来团队协作或多负载均衡服务器的CI/CD模式做铺垫，尤其不想在生产服务器上构建。请问针对单EC2实例的Next/Node应用，在当前手动部署与完整CI/CD之间，是否有更高效、低风险、低停机时间的过渡部署步骤？还是只能维持现状或直接搭建CI/CD？

不用直接跳完整CI/CD，以下几个轻量方案能解决当前痛点，同时为未来扩展铺路：

1. 本地完成全构建，仅同步成品到EC2 #

把所有构建步骤挪到本地（或开发机），生产服务器只负责运行成品：

• 本地拉取自定义react-share代码，构建打包成react-share-4.4.1.tgz
• 在主项目目录执行npm install（自动关联本地tgz依赖）、npx prisma generate、next build
• 用rsync或scp把构建好的.next目录、node_modules（建议只保留生产依赖，可先执行npm ci --production）、prisma目录下的客户端文件同步到EC2的部署目录
• 远程执行pm2 restart完成部署

这样生产服务器不用装构建工具、不用处理依赖编译，彻底避免生产环境的构建风险。

2. 写bash脚本自动化手动流程 #

把你现在手动敲的命令整合成一个脚本，一键完成部署，减少人为失误：
示例脚本（可根据实际路径调整）：

#!/bin/bash
set -e # 某一步失败则终止脚本

# 构建自定义react-share
cd ../react-share
git pull
npm install
npm run build
npm pack

# 回到主项目构建
cd ../next-project
git pull
npm install
npx prisma generate
next build

# 同步到EC2
rsync -avz --exclude='node_modules/.cache' .next/ user@your-ec2-ip:/path/to/production/.next
rsync -avz node_modules/ user@your-ec2-ip:/path/to/production/node_modules
rsync -avz prisma/ user@your-ec2-ip:/path/to/production/prisma

# 远程重启服务
ssh user@your-ec2-ip "pm2 restart next-app"

脚本里的set -e能避免某一步出错后继续执行导致的混乱，还可以加日志输出，方便排查问题。

3. 轻量CI（仅构建）+ 手动/脚本部署 #

用GitHub Actions做最基础的CI：只负责拉取代码、构建产物，部署还是用脚本或手动同步。
配置示例（.github/workflows/build.yml）：

name: Build Next.js App
on: [push]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Set up Node.js
        uses: actions/setup-node@v4
        with:
          node-version: 20
      - name: Build react-share
        run: |
          git clone https://github.com/your-repo/react-share.git ../react-share
          cd ../react-share
          npm install
          npm run build
          npm pack
      - name: Build Next.js app
        run: |
          cd ../next-project
          npm install
          npx prisma generate
          next build
      - name: Upload build artifacts
        uses: actions/upload-artifact@v4
        with:
          name: next-build
          path: |
            .next/
            node_modules/
            prisma/

构建完成后，你可以手动下载 artifacts 同步到EC2，或者在Actions里加一步用rsync直接同步到EC2（需要把EC2的SSH密钥配置到GitHub Secrets）。这种方式既避免了本地环境差异，又不用搭建复杂的CD流程，未来扩展成完整CI/CD也很容易。

4. 蓝绿部署降低停机风险 #

在单EC2上实现简易蓝绿部署，零停机且能快速回滚：

• 在EC2上创建两个部署目录：/var/app/blue和/var/app/green
• 当前运行的版本放在blue，部署新版本时把构建好的代码放到green
• 启动green目录的服务（用不同端口测试），确认没问题后，修改Nginx反向代理的指向到green的端口，或者直接切换pm2的应用目录
• 确认新版本稳定后，再停掉blue的服务；如果出问题，立刻切回blue

这种方式能把部署风险降到最低，尤其适合生产环境的重要应用。

内容的提问来源于stack exchange，提问作者philolegein