从零开始的持续集成实战：一次真实项目中的数据备份优化

上个月，我们团队接手了一个老旧的后台系统重构任务。这个系统原本没有自动化流程，每次上线都要手动打包、上传服务器，再小心翼翼地备份旧数据。有次操作失误，差点把生产环境的用户记录搞丢了。那次之后，我们下定决心引入持续集成，尤其是把数据备份环节彻底自动化。

为什么把备份放进CI流程

很多人觉得持续集成就是跑测试、打包代码，其实不然。真正稳定的系统，必须在每次部署前自动完成数据快照。我们用的是 GitLab CI + Docker + MySQL，整个流程跑通后，每次 push 代码到 main 分支，都会触发一个带时间戳的数据库备份。

具体是怎么做的

我们在 .gitlab-ci.yml 中加了一个 backup 阶段：

backup_database:
  stage: backup
  script:
    - mkdir -p backups
    - mysqldump -h$DB_HOST -u$DB_USER -p$DB_PASS $DB_NAME > backups/db_$(date +\"%Y%m%d_%H%M\").sql
    - aws s3 cp backups/db_$(date +\"%Y%m%d_%H%M\").sql s3://our-backup-bucket/
  only:
    - main

这段脚本会在每次主分支更新时自动执行。先用 mysqldump 把当前数据库导出，文件名带上精确时间，再上传到 S3。哪怕后续部署出问题，也能立刻回滚到最近一次的状态。

遇到过的问题

刚开始运行时，有次备份失败了，但 CI 流程还是标记为成功。排查发现是 mysqldump 命令没加错误检测。后来我们加上 set -e，并对关键命令做校验：

script:
  - set -e
  - mysqldump ... || { echo \"Backup failed\"; exit 1; }

这样一来，只要备份出错，整个流程就会中断，避免出现“假成功”的情况。

现在的工作节奏变了

以前每次上线都像打仗，大家围在电脑前轮流操作。现在，我早上到公司泡杯咖啡，看看昨天晚上的 CI 日志，确认备份和部署都完成了。就算临时要回滚，点一下按钮就行。最实在的变化是，没人再半夜被叫起来救火了。

这套流程跑了几周后，产品同事也放心多了。她说：‘你们现在上线跟换件衣服似的，我都感觉不到。’ 这大概就是自动化最大的意义——让变化变得平常。