背景：GitLab CI/CD与Jenkins的持续交付实战

当开发者还在手动执行scp或rsync部署代码时，运维团队的报警系统已因频繁出错亮起红灯。如今，通过将GitLab CI/CD与Jenkins相结合，我们不仅能实现真正的代码无痛部署，还能构建出符合企业级规范的自动化交付流水线。本文将手把手带你在Linux环境下打造这样的部署系统。

1. 工具选择与技术栈定位

本次示例采用GitLab CE v15.0 + Jenkins v2.387组合方案，操作系统环境为Ubuntu 22.04 LTS。之所以选择这两个工具的协同方案，是因为：

  • GitLab CI/CD擅长代码版本管理与流水线触发
  • Jenkins在复杂工作流编排和跨平台调度上表现优异
  • 两者结合可实现提交即部署的全链路自动化

2. GitLab CI/CD核心配置解析

在项目根目录创建.gitlab-ci.yml文件：

image: python:3.9-slim

# 定义流水线阶段
stages:
  - lint
  - build
  - deploy

# 代码静态检查阶段
code_quality:
  stage: lint
  script:
    - pip install pylint
    - pylint --rcfile=.pylintrc app/*.py
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'

# Docker镜像构建阶段 
build_image:
  stage: build
  script:
    - docker build -t ${CI_REGISTRY_IMAGE}:${CI_COMMIT_SHORT_SHA} .
    - docker push ${CI_REGISTRY_IMAGE}:${CI_COMMIT_SHORT_SHA}
  only:
    - master

# 调用Jenkins执行部署  
trigger_jenkins:
  stage: deploy
  trigger:
    project: ops/jenkins-deploy
    strategy: depend
  variables:
    ENVIRONMENT: "production"
    COMMIT_SHA: $CI_COMMIT_SHA

该配置文件实现了从代码检查→镜像构建→触发Jenkins部署的完整流程。其中trigger_jenkins阶段通过API调用关联的Jenkins项目。

3. Jenkins任务对接实例

在Jenkins中创建名为deploy-to-prod的流水线任务，配置如下Jenkinsfile：

pipeline {
    agent any
    
    environment {
        DEPLOY_SSH = credentials('prod-server-key')
    }

    stages {
        stage('Pull Image') {
            steps {
                script {
                    sh '''
                        docker pull ${CI_REGISTRY_IMAGE}:${COMMIT_SHA}
                        docker tag ${CI_REGISTRY_IMAGE}:${COMMIT_SHA} app:latest
                    '''
                }
            }
        }
        
        stage('Deploy') {
            steps {
                sshagent(['prod-server-key']) {
                    sh "ssh -o StrictHostKeyChecking=no ubuntu@prod-server.example.com 'docker-compose down && docker-compose up -d'"
                }
            }
        }
    }
    
    post {
        success {
            slackSend channel: '#deploy-notify', message: "生产环境部署成功: ${env.BUILD_URL}"
        }
        failure {
            emailext body: '部署失败请立即检查', subject: '紧急：生产部署失败', to: 'devops@example.com'
        }
    }
}

此配置实现了：

  1. 从私有仓库拉取指定版本的Docker镜像
  2. 通过SSH密钥连接到生产服务器
  3. 使用docker-compose执行零停机更新
  4. 集成消息通知机制

4. 典型应用场景剖析

场景一：紧急热修复部署

  1. 开发者在功能分支提交修复代码
  2. 创建Merge Request自动触发代码审查流水线
  3. 通过后合并到master分支触发镜像构建
  4. GitLab自动触发Jenkins生产环境部署 全过程从代码提交到生产发布仅需8分钟

场景二：多环境滚动更新 通过在Jenkins中配置parallel阶段，可实现预发布环境验证→灰度发布→全量部署的三段式升级策略，最大限度降低部署风险。

5. 技术方案优劣对比

优势组合：

  • 代码触发链路清晰（GitLab Webhook → Jenkins Job）
  • 制品版本通过Docker镜像哈希严格绑定
  • 审计日志天然存在于两个系统（GitLab流水线日志 + Jenkins控制台输出）

潜在挑战：

  • 双系统维护成本需要考虑（建议使用Ansible统一配置）
  • 密钥管理需同时配置GitLab Variables和Jenkins Credentials
  • 跨系统调试复杂度较高（建议在测试环境完整演练）

6. 避坑指南与最佳实践

环境隔离策略：

# 采用不同Docker网络隔离构建环境
docker network create ci-network
docker run --network ci-network -v ${PWD}:/app builder-image

密钥安全方案：

  • GitLab采用File类型变量存储TLS证书
  • Jenkins使用凭据管理器绑定SSH密钥
  • 通过Vault实现动态密钥分发（生产环境推荐）

性能优化技巧：

  1. 构建缓存策略：
# GitLab Runner配置添加缓存
cache:
  paths:
    - venv/
    - .cache/pip
  1. Jenkins节点预热机制：
// 预载Docker基础镜像
pipeline {
    stages {
        stage('Preheat') {
            steps {
                sh 'docker pull python:3.9-slim || true'
            }
        }
    }
}

7. 架构演进方向

随着业务复杂度提升，可逐步引入：

  • Argo CD实现K8s声明式部署（替代部分Jenkins功能）
  • SonarQube加强质量门禁（集成到GitLab MR检查）
  • 分布式Runner集群（通过Kubernetes Executor实现弹性扩缩容）