手动部署的时代
项目刚开始，部署都是手动的。流程是这样的：
- 本地构建：
npm run build - 压缩文件：打包成 zip
- 上传服务器：用 FTP 上传
- 解压文件：SSH 登录，解压文件
- 重启服务：重启 Nginx 或 Node.js
- 检查日志：看有没有错误
整个过程要 1 个小时，而且经常出错。上传错了文件、解压错了目录、重启错了服务，各种问题都有。
第一次尝试：Shell 脚本
手动部署太麻烦，我们写了 Shell 脚本自动化。脚本做了这些事：
- 构建项目
- 压缩文件
- 上传服务器
- 解压文件
- 重启服务
用脚本后，部署时间从 1 小时降到 10 分钟。但问题还是很多：
- 脚本经常出错，要手动修复
- 不同环境要改脚本，很麻烦
- 没有回滚机制，出问题很麻烦
第二次尝试：GitLab CI
用 Shell 脚本还是不够，我们决定用 GitLab CI。配置 CI/CD，自动构建和部署。
但配置 CI/CD 很麻烦，花了 3 个月才搞定：
- 配置 Runner，花了一周
- 写构建脚本，花了两周
- 配置部署脚本，花了两周
- 测试和调试，花了一个月
遇到的问题
问题一：环境变量
CI/CD 要用环境变量，但不同环境变量不同。测试环境、预发布环境、生产环境，变量都不一样。
我们在 GitLab 里配置了变量组，按环境分组。但变量多了，管理起来很麻烦。
问题二：构建缓存
每次构建都要安装依赖，很慢。我们用了缓存，但缓存经常失效。
后来用了 pnpm，缓存更稳定，构建时间从 10 分钟降到 3 分钟。
问题三：部署回滚
部署出问题，要回滚。但回滚很麻烦，要手动操作。
我们做了自动回滚：部署后自动测试，失败就回滚。但自动回滚也有问题，有时候误判。
现在的流程
现在的部署流程：
- 代码 push 到 GitLab
- 自动触发 CI，构建项目
- 构建成功后，自动部署到测试环境
- 测试通过后，手动触发生产部署
- 部署后自动测试，失败就回滚
整个过程自动化，部署时间从 1 小时降到 5 分钟。
如果重新开始
如果重新做一个项目，我会：
- 一开始就配置 CI/CD，不要后面改
- 做好环境变量管理，不要分散
- 做好构建缓存，提升构建速度
- 做好部署回滚，降低风险
总结
部署自动化很重要，但要早规划。如果等出问题再改，成本很高。
如果你们项目也在做自动化部署，建议先做好规划，再执行。规划要全面，执行要严格，不然很容易出问题。
另外，部署自动化是持续优化的过程。一开始可能不完美，但慢慢优化，总能做好。