以前改完一行代码，得手动打包、上传服务器、重启服务，生怕漏了哪一步，半夜被报警短信叫醒。现在用 GitLab CI，提交代码那一刻，部署就自动跑起来了——就像你发条微信，对方秒回，整个流程安静又靠谱。
先搞懂：CI 是啥，跟部署有啥关系？
CI（Continuous Integration，持续集成）本意是频繁合并代码并自动验证。但在 GitLab 里，它早就不止‘集成’这么简单——配合 .gitlab-ci.yml 文件，它能编译、测试、构建镜像、推送到服务器，甚至执行数据库迁移。换句话说，它就是你团队的‘数字运维员’，不请假、不摸鱼、不手抖。
一个真实可用的部署流程长这样
假设你维护一个 Python Flask 小项目，部署到阿里云轻量应用服务器，不用 Docker，纯源码 + Nginx + Gunicorn。下面这个 .gitlab-ci.yml 就够用：
stages:
- build
- deploy
build-job:
stage: build
script:
- pip install --upgrade pip
- pip install -r requirements.txt --target ./dist
artifacts:
paths:
- dist/
expire_in: 1 hour
deploy-prod:
stage: deploy
only:
- main
script:
- ssh -o StrictHostKeyChecking=no $DEPLOY_USER@$DEPLOY_HOST "mkdir -p /var/www/myapp"
- rsync -avz --delete dist/ $DEPLOY_USER@$DEPLOY_HOST:/var/www/myapp/dist/
- rsync -avz app.py config.py $DEPLOY_USER@$DEPLOY_HOST:/var/www/myapp/
- ssh -o StrictHostKeyChecking=no $DEPLOY_USER@$DEPLOY_HOST "cd /var/www/myapp && sudo systemctl restart myapp.service"
environment: production注意几个实操细节：
$DEPLOY_USER和$DEPLOY_HOST是你在 GitLab 项目 Settings → CI/CD → Variables 里配的变量，密码不用明文写死；- 用
rsync同步比scp更稳，删旧传新一步到位； artifacts把构建产物临时存下来，供部署阶段直接拿，避免重复安装依赖。
别跳过这三步，否则部署总失败
1. Runner 必须装对地方：如果你部署目标是私有服务器，推荐在那台机器上装 shell executor 类型的 Runner（别用默认的 docker 类型，免得折腾网络和权限）。命令就一行：sudo gitlab-runner register --url https://gitlab.example.com/ --token xxx --executor shell --description "prod-server-runner"。
2. SSH 免密要通透：Runner 所在机器（也就是你的服务器）必须能用密钥免密登录自己（因为部署脚本里有 ssh 命令），运行 ssh-keygen && ssh-copy-id $USER@localhost 就搞定。
3. systemctl 服务文件提前写好：比如 /etc/systemd/system/myapp.service，内容包含 WorkingDirectory、ExecStart、Restart=always，不然 restart 命令会静默失败。
小技巧：本地模拟 CI 流程
不想每次 push 都试错？在自己电脑终端里跑一遍类似命令：
pip install -r requirements.txt --target ./tmp-dist
rsync -avz ./tmp-dist/ user@server:/var/www/myapp/dist/
ssh user@server 'sudo systemctl restart myapp'顺了再挪进 CI 文件里，省得反复看 pipeline 失败日志抓瞎。
部署这事，真没那么多玄学。把流程拆成‘构建→传文件→重启服务’三步，配上 GitLab CI 这个顺手工具，谁都能搭出干净利落的自动化流水线。上线不再是提心吊胆的‘操作’，而是一次确认提交后的自然结果。