小王刚接手公司一个内部管理后台，每次改完一行 CSS，都要手动打包、上传服务器、重启 Nginx，一来二去半小时没了。直到他把项目接入 GitLab CI，现在点下「Push」，5 分钟后新功能就跑在生产环境了——整个部署流程全自动化，人只管写代码。
什么是 GitLab CI 的部署流程？
简单说，就是你往 GitLab 仓库 push 代码时，GitLab 自动拉取、构建、测试、打包，最后把可运行的产物推到服务器或云平台的过程。它不靠人点鼠标，靠的是你写在 .gitlab-ci.yml 文件里的一套指令。
三步搭起基础部署流程
假设你有个 Vue 前端项目，要部署到一台 Ubuntu 服务器上，Nginx 已装好，目录是 /var/www/myapp。
1. 写好 .gitlab-ci.yml
在项目根目录新建文件：.gitlab-ci.yml，内容如下：
stages:
- build
- deploy
build-job:
stage: build
image: node:18-alpine
script:
- npm ci
- npm run build
artifacts:
- dist/**
deploy-job:
stage: deploy
image: alpine:latest
before_script:
- apk add openssh-client rsync
script:
- rsync -avz --delete dist/ user@192.168.1.100:/var/www/myapp/
only:
- main这里定义了两个阶段：build（安装依赖、打包），deploy（用 rsync 把打包好的 dist 目录同步到服务器）。注意最后一行 only: - main，表示只在 main 分支推送时触发部署。
2. 配置服务器免密登录
GitLab Runner 要能连上你的服务器，不能每次输密码。在 GitLab 项目设置 → CI/CD → Variables，新增变量：
- SSH_PRIVATE_KEY：粘贴你本地生成的私钥（
id_rsa内容，开头是-----BEGIN OPENSSH PRIVATE KEY-----） - DEPLOY_HOST：填服务器 IP，比如
192.168.1.100 - DEPLOY_USER：填登录用户名，比如
user
然后把 .gitlab-ci.yml 中的 rsync 行改成支持密钥的方式：
script:
- mkdir -p ~/.ssh
- echo "$SSH_PRIVATE_KEY" | tr -d '\r' > ~/.ssh/id_rsa
- chmod 600 ~/.ssh/id_rsa
- ssh-keyscan -H $DEPLOY_HOST >> ~/.ssh/known_hosts
- rsync -avz --delete dist/ $DEPLOY_USER@$DEPLOY_HOST:/var/www/myapp/3. 提交并观察流水线
保存文件，git commit 并 push 到 main 分支。回到 GitLab 项目首页，点左侧「CI/CD」→「Pipelines」，就能看到一条新流水线正在运行。点进去看每个步骤的日志，绿色对勾亮起，说明部署成功了。
刷新你的网站，新页面已经在线上跑着。下次改个按钮文字，再 push，整个过程不再需要你碰服务器终端。
进阶提示（按需加）
想更稳一点？可以在 deploy 前加个 test 阶段跑单元测试；想区分环境？把 deploy-job 拆成 deploy-staging 和 deploy-prod，配合 protected branches 和 manual trigger 控制上线节奏；静态资源想走 CDN？把 rsync 换成 aws s3 sync 或 gsutil rsync 就行。
GitLab CI 的部署流程不是黑盒子，它就是一堆脚本 + 触发规则 + 环境变量拼起来的自动化链条。写清楚每一步要干什么，剩下的，交给 GitLab 去跑。