正文

持续集成部署踩坑实录，从月月修服务器到躺平收钱，我只用了这三招

程序员老王
程序员老王 V管理员 /26阅读/3评论
0729
文章最后更新时间2026年07月29日，若文章内容或图片失效，请留言反馈！

那个让我连续加班三个月的噩梦

四年前,我接手了一个日活5万的论坛站点，那时候的部署流程堪称原始时代——FTP上传代码，SSH进服务器手动执行命令，数据库迁移全靠手打SQL，每个月总有那么一两天，凌晨三点被报警短信炸醒，爬起来修服务器。

最惨的一次,我手滑把线上数据库表删了，那晚我对着屏幕上的drop table像被人浇了一盆冷水，手指发抖地翻了三小时备份文件，从那之后，我下定决心：要么用自动化工具把自己从苦海里捞出来，要么就等着被老板炒掉。

持续集成部署踩坑实录，从月月修服务器到躺平收钱，我只用了这三招

持续集成部署踩坑实录，从月月修服务器到躺平收钱，我只用了这三招

CI/CD不是玄学，是救命稻草

持续集成部署这四个字听着高大上，说白了就是：代码改完自动测试、自动打包、自动部署到服务器，我用的是最简单的方案：GitHub + GitHub Actions + 阿里云ECS。

踩坑的第一个点：代码放到哪里？ 很多人上来就纠结GitLab还是Jenkins，我告诉你，个人站或小团队，GitHub Actions就够用了，别学大厂造轮子，浪费的时间够你喝半年咖啡。

具体配置我吃过不少亏,gitlab-ci.yml文件里，我一开始把branches写成了branch，结果每次推送代码，流水线都不触发，蹲在服务器前等了半小时才反应过来，还有一次，actions脚本里忘了设置cache，每次构建都要重新下载依赖，一个简单的WordPress站点，构建时间从2分钟拖到15分钟。

推荐的实用方案：

name: Deploy to Server
on:
  push:
    branches: [main]
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Deploy via rsync
        uses: easingthemes/ssh-deploy@v2
        with:
          SSH_PRIVATE_KEY: ${{ secrets.SSH_PRIVATE_KEY }}
          ARGS: "-avz --delete"
          SOURCE: "./"
          REMOTE_HOST: ${{ secrets.HOST }}
          REMOTE_USER: "root"
          TARGET: "/var/www/html"

这个配置看起来简单,但暗藏杀机。--delete参数有个坑：如果你本地的/dist目录是空的，它会把你服务器上的所有文件都删光，我第一次用这个参数，差点把整个服务器的Nginx配置都清空了，幸亏提前做了快照。

服务器和域名——那些年我交的智商税

域名和服务器是CI/CD的基础，但这里踩坑的人最多。

域名解析TTL：我见过太多人把TTL设置成3600秒（1小时），这意味着你改完DNS，要等一个小时才生效，如果你像我一样在深夜改域名，那全站离线的一小时足够让你被用户骂到怀疑人生，把TTL设成60秒，改完等两分钟，测试通过再调回默认值。

SSL证书：Let's Encrypt的免费证书很好用，但千万别手动续期，我第二年因为忘记续期，整个站挂了整整两天，用acme.sh脚本配合cron自动续期，设置每天凌晨3点检查一次，比什么都靠谱。

服务器内存：1GB内存的轻量云服务器看起来够用，但如果你跑CI/CD的构建任务，内存会被GitHub Actions的runner吃光，我最后选了2核4G的配置，多花的钱远少于半夜爬起来重启服务器浪费的时间。

程序层面的劫后余生

数据库迁移：这是CI/CD里最容易翻车的地方，我见过最惨的案例：某人把线上数据库的连接字符串写进了database.php，提交代码时忘了加密，结果整个数据库被公开，解决方案很简单：用环境变量。.env文件永远不要提交到Git仓库，而是通过CI/CD的secrets管理。

配置文件冲突：本地开发环境和线上环境肯定不一样，我踩过的坑是：本地用MySQL，线上用MariaDB，数据库驱动名字不一样，一上线就报错，解决方案：在CI/CD流水线里加一个编译步骤，把配置文件按照环境变量自动生成。

静态资源缓存：图片、CSS、JS文件更新后，用户浏览器还是旧版本，整个站点瞬间变成“90年代风格”，我在Nginx里配置了文件版本号，每次部署自动生成新版本号，再配合CDN缓存清理，总算解决了这个问题。

长期维护——比建站更难的守业

监控告警：别以为CI/CD部署完就能躺平，我吃过最大的亏是：流水线运行失败时，GitHub只往我的邮箱发通知，而我每天要看几百封邮件，直接忽略了，后来改成微信群机器人+钉钉通知，失效率从30%降到0。

日志切割：服务器硬盘被日志撑爆是什么体验？我遇到过，整个站显示“No space left on device”，吓得赶紧去阿里云扩容，结果发现只是/var/log里的日志占了30GB，配置logrotate，按天切割，保留7天，成了我维护列表里的铁律。

备份策略：CI/CD自动部署之后，最容易让人松懈的就是备份，我见过有人把备份脚本和CI/CD绑在一起，结果流水线失败，备份也跟着停了，还是那句老话：三条备份规则：本地一份、服务器一份、云存储一份，缺一不可。

给新手的三条建议

  1. 从小做起：别一开始就想着全自动化，先用手动部署跑通整个流程，再慢慢加自动化步骤，我第一个CI/CD项目只做了“自动scp文件到服务器”这一步，用了三个星期才研究明白。

  2. 理解失败：第一次跑通CI/CD流水线，别高兴太早，我那个论坛的流水线第一次跑成功，结果部署上去发现所有中文都变成乱码了——PHP的default_charset设置没配，多测试几次，把各种可能失败的情况都模拟一遍。

  3. 留有余地：永远保留手动部署的能力，我见过最狠的情况：CI/CD平台挂了，整个团队没法上线任何代码，我在服务器上留了一个deploy.sh脚本，用SSH直接执行，虽然原始，但至少能救命。

最后说一句：持续集成部署不是终点，而是起点，真正好的运维，是让你忘了运维的存在，别急着追求高大上的工具链，把基础打扎实了，比什么都强。