GitLab如何实现持续集成与部署

GitLab CI/CD 实现步骤与示例

核心概念与前置条件

核心组成：在仓库根目录放置 .gitlab-ci.yml 定义流程；使用 GitLab Runner 执行作业；借助 Pipeline/Job/Stage 组织构建、测试、部署；通过 环境 Environment、变量 Variables、制品 Artifacts、缓存 Cache 管理配置、产物与依赖；在 UI 中查看 管道图、作业日志、报告与指标 进行监控与优化。Runner 可在 Linux 服务器安装并注册到项目或实例，执行器可选 Docker/Shell 等。以上要素构成了 GitLab 内置 CI/CD 的最小闭环。

快速上手流程

步骤 1 安装并注册 Runner（Linux 示例）
- 安装 Runner：添加仓库后执行安装命令（如 apt/yum），注册命令为 gitlab-runner register，按提示填写 GitLab 实例 URL 与 Registration Token（在项目 Settings > CI/CD > Runners 获取），选择执行器（如 docker/shell）与标签。注册完成后可在项目 Runner 列表看到状态。
步骤 2 编写 .gitlab-ci.yml
- 定义 stages（如 build/test/deploy），为每个 stage 编写 jobs，在 script 中执行构建、测试、部署命令；按需使用 artifacts 传递产物、cache 加速依赖、variables 管理配置、environment 标记部署环境。
步骤 3 提交并触发
- 将 .gitlab-ci.yml 提交到仓库后，推送代码或创建 Merge Request 会自动触发流水线；也可在 CI/CD > Pipelines 页面手动运行。
步骤 4 查看与调试
- 在 Pipelines/Jobs 页面查看 实时日志、失败原因、测试报告 与耗时，必要时重跑作业或调整配置。

完整示例

示例一通用 Node.js 流水线（含产物与缓存）

stages:
  - build
  - test
  - deploy

variables:
  NODE_VERSION: "18"

cache:
  paths:
    - node_modules/

build_job:
  stage: build
  image: node:$NODE_VERSION
  script:
    - npm ci
    - npm run build --if-present
  artifacts:
    paths:
      - build/
    expire_in: 1 week

test_job:
  stage: test
  image: node:$NODE_VERSION
  script:
    - npm test -- --ci
  dependencies:
    - build_job

deploy_staging:
  stage: deploy
  image: alpine:latest
  script:
    - echo "Deploying to staging..."
    # 例如 rsync/ssh 部署到你的服务器
  environment:
    name: staging
    url: https://staging.example.com
  only:
    - main

要点：用 cache 复用 node_modules，用 artifacts 将 build/ 传递给测试与部署；通过 environment 标记环境，用 only 限定分支触发。

示例二 Docker 镜像构建与部署（推送到 GitLab 容器镜像库）

stages:
  - build
  - test
  - deploy

variables:
  DOCKER_DRIVER: overlay2
  IMAGE_TAG: $CI_REGISTRY_IMAGE:$CI_COMMIT_REF_SLUG

before_script:
  - docker login -u "$CI_REGISTRY_USER" -p "$CI_REGISTRY_PASSWORD" $CI_REGISTRY

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

test_job:
  stage: test
  image: docker:24
  services:
    - docker:24-dind
  script:
    - docker run --rm $IMAGE_TAG npm test -- --ci
  only:
    - merge_requests
    - main

deploy_prod:
  stage: deploy
  image: alpine:latest
  script:
    - echo "Deploying $IMAGE_TAG to production..."
    # 例如 docker-compose pull && docker-compose up -d
  environment:
    name: production
    url: https://prod.example.com
  only:
    - main

要点：使用 docker:dind 作为服务容器进行镜像构建与运行；通过 CI_REGISTRY_IMAGE/CI_COMMIT_REF_SLUG 等内置变量规范镜像标签；在 only 中区分 merge_requests（用于预览与质量门禁）与 main（用于生产发布）。

最佳实践与监控优化

配置与复用
- 使用 include 引入公共模板、extends 复用作业片段，减少重复；按项目类型沉淀 Dockerfile 与 CI 模板库，便于统一规范与快速接入。
质量与安全
- 在 Merge Request 阶段运行 单元测试、代码扫描（如 SonarQube），必要时设置 allow_failure: true 作为门禁参考；将 Secrets 配置为 Protected/ Masked 变量，避免明文泄露；制品与镜像使用 短生命周期标签（如 CI_COMMIT_SHA/CI_COMMIT_REF_SLUG），配合 expire_in 控制存储成本。
性能与成本
- 合理使用 cache 与 artifacts，将跨作业共享的依赖与构建产物分层管理；为 Runner 选择合适的 执行器与标签，必要时使用 Docker 层缓存 与 多阶段构建 减少构建时长；通过 管道图、作业日志、报告与指标 定位瓶颈并持续优化。