GitLab CI/CD流水线搭建：代码提交到自动部署全流程实践

CI/CD流水线是DevOps实践的核心设施。GitLab自带CI/CD，只需在仓库放一个.gitlab-ci.yml，配合GitLab Runner即可完成构建、测试、部署。相比Jenkins，GitLab CI配置即代码、可视化流水线、天然与代码仓库联动。本文从Runner部署到生产发布完整走一遍。

CI/CD流水线配置结构与阶段定义

流水线由阶段（stages）和作业（jobs）组成。每个作业在独立环境中执行，只有全部作业成功才进入下一阶段。基础配置：

stages:
  - build
  - test
  - deploy

variables:
  IMAGE_TAG: registry.example.com/app:${CI_COMMIT_SHORT_SHA}

default:
  tags:
    - docker

GitLab Runner安装注册与执行环境

Runner是执行作业的Agent，官方提供docker executor，每个作业在容器内运行：

# 安装 runner（容器方式）
docker run -d --name gitlab-runner --restart always \
  -v /srv/gitlab-runner/config:/etc/gitlab-runner \
  -v /var/run/docker.sock:/var/run/docker.sock \
  gitlab/gitlab-runner:latest

# 注册 runner
docker exec gitlab-runner gitlab-runner register \
  --url https://gitlab.example.com \
  --token <注册token> \
  --executor docker \
  --docker-image alpine:3.18 \
  --description "shared-runner"

注册token在项目 Settings – CI/CD – Runners 页面获取。注册后Runner状态变为绿色online即可使用。

构建与测试阶段：镜像打包和代码检查

构建阶段打镜像推私有仓库，测试阶段跑lint与单测，任一失败阻断发布：

build-image:
  stage: build
  image: docker:24
  services:
    - docker:24-dind
  script:
    - docker build -t $IMAGE_TAG .
    - docker push $IMAGE_TAG
  only:
    - main

unit-test:
  stage: test
  image: node:20
  script:
    - npm ci
    - npm run lint
    - npm run test:coverage
  only:
    - main
    - merge_requests

部署阶段：SSH远程发布与环境隔离

生产发布用ssh到服务器拉取新镜像并重启容器，用when: manual做人工确认门禁，environment关联部署环境便于回滚：

deploy-prod:
  stage: deploy
  image: alpine:3.18
  before_script:
    - apk add --no-cache openssh-client
  script:
    - eval "$(ssh-agent -s)" && ssh-add <(echo "$SSH_PRIVATE_KEY")
    - ssh -o StrictHostKeyChecking=no deploy@prod \
        "docker pull $IMAGE_TAG && docker compose up -d app"
  environment:
    name: production
    url: https://app.example.com
  when: manual
  only:
    - tags

敏感信息如SSH密钥、密码一律用GitLab CI/CD Variables（Masked+Protected），严禁写进仓库。

流水线缓存优化与失败排查

提升流水线速度的常用手段：依赖缓存（npm ci、pip缓存到runner缓存目录）、镜像分层、并发作业拆分。失败排查：看作业日志定位（点击红色失败Job展开日志），最常见三类——Runner离线（检查网络与token）、Docker权限（挂载docker.sock）、变量引用错误（Masked变量在非保护分支不可用）。逐步修改后重跑，直到全绿再合并主干。

流水线安全与制品管理

保护分支：main/tags设置流水线必须成功才允许合并（Merge Checks）。制品：构建产物用artifacts上传，供后续作业或下载排查使用。回滚策略：保留上一版本镜像标签，发布失败时docker compose 回退标签重启即可。CI/CD流水线建成后，发布从几十分钟人工操作压缩到分钟级，是SRE效率提升的直接手段。