小王在公司负责一个内部管理后台，以前每次改完代码都要手动打包、上传服务器、重启服务，一不小心就漏掉某一步，半夜被报警短信叫醒是常事。后来他把整个部署流程搬进了 GitLab CI，现在只要 git push 一下，10 分钟内新版本就稳稳跑在生产环境了——这背后，就是一套清晰可控的部署流程。
什么是 GitLab CI 部署流程？
简单说，就是用 .gitlab-ci.yml 文件定义「代码提交后该自动做什么」。它不是神秘脚本，而是一套可读、可改、可追溯的自动化流水线：提交 → 构建 → 测试 → 打包 → 部署 → 通知，每一步都在 GitLab 页面里看得清清楚楚。
三步搭起基础部署流程
假设你有个 Vue 前端项目，要自动构建并同步到 Nginx 服务器上，可以这样写：
stages:
- build
- deploy
build-dist:
stage: build
image: node:18-alpine
script:
- npm ci
- npm run build
artifacts:
paths:
- dist/
expire_in: 1 week
deploy-to-prod:
stage: deploy
image: alpine:latest
before_script:
- apk add openssh-client rsync
script:
- rsync -avz --delete dist/ user@192.168.1.100:/var/www/html/
only:
- main注意几个关键点：
• artifacts 把构建好的 dist 目录存下来，供下一步使用；
• only: - main 表示只在 main 分支推送时触发部署；
• rsync 比 scp 更稳妥，支持断点续传和差异同步。
加个安全层：用 SSH 密钥免密登录
直接写密码在脚本里太危险。GitLab 提供 CI/CD Variables 功能，在项目设置 → CI/CD → Variables 里添加：SSH_PRIVATE_KEY（类型选 File），粘贴你的私钥内容。
然后在 deploy 作业里加一行：
before_script:
- mkdir -p ~/.ssh
- echo "$SSH_PRIVATE_KEY" | tr -d '\r' > ~/.ssh/id_rsa
- chmod 600 ~/.ssh/id_rsa
- ssh-keyscan 192.168.1.100 >> ~/.ssh/known_hosts这样既不用暴露密码，也不用担心密钥泄露到日志里。
后端项目怎么搞？以 Python Flask 为例
后端更关注测试和进程管理。你可以让 CI 先跑单元测试，再用 systemd 重载服务：
test:
stage: build
image: python:3.11
script:
- pip install -r requirements.txt
- pytest tests/
deploy-api:
stage: deploy
image: alpine:latest
before_script:
- apk add openssh-client
script:
- ssh user@192.168.1.101 "cd /opt/myapp && git pull && pip install -r requirements.txt && systemctl restart myapp.service"当然，更推荐用容器化部署，但对中小团队来说，这种轻量方式已经省下大半运维时间。
别忘了给团队留条“逃生通道”
自动部署再稳，也得有人工干预入口。GitLab CI 支持手动触发作业，在 .gitlab-ci.yml 里加 when: manual：
rollback:
stage: deploy
when: manual
script:
- ssh user@192.168.1.100 "cd /var/www/html && git reset --hard HEAD~1 && git pull"点击一下就能回滚，比翻聊天记录找旧包快多了。
部署流程不是越复杂越好，而是越清晰、越可维护越好。GitLab CI 的好处在于：所有逻辑都在代码里，新人 clone 项目就能看到整套发布规则，不用靠口口相传或翻笔记找命令。