2931 字
15 分钟
CI/CD 从入门到精通:现代运维的核心引擎

为什么我们需要CI/CD?#

在传统的软件开发模式中,我们往往经历过这样的噩梦:开发人员各自在本地编写代码,经过数周甚至数月的开发后,在某个”黑色星期五”将所有代码合并到主干,然后花费数天甚至数周的时间解决各种冲突和bug;测试人员只能在代码全部合并完成后才能开始测试,发现的问题又需要开发人员重新修改,反复迭代;最终部署上线时,需要运维人员手动执行一系列复杂的命令,稍有不慎就会导致线上故障,整个团队通宵达旦地救火。

核心痛点

传统开发模式的三大致命缺陷:

  • 集成地狱:代码合并冲突频繁,修复成本高昂
  • 测试滞后:问题发现晚,修复周期长
  • 部署风险:人工操作易出错,回滚困难

这种”瀑布式”的开发和交付模式,在今天快速变化的互联网时代已经完全无法满足需求。市场要求我们更快地交付新功能,更快地响应用户反馈,同时还要保证软件的质量和稳定性。而CI/CD(持续集成/持续交付)正是解决这一矛盾的关键技术,它已经成为现代DevOps文化的核心支柱,也是每一位运维工程师必须掌握的核心技能。

什么是CI/CD?#

CI/CD实际上包含了三个紧密相关但又有所区别的概念:持续集成(Continuous Integration)、持续交付(Continuous Delivery)和持续部署(Continuous Deployment)。

持续集成(CI)#

持续集成是指开发人员频繁地(通常是每天多次)将代码合并到共享的主干分支中。每次合并都会触发自动化的构建和测试流程,以确保新代码不会破坏现有功能。

CI最佳实践
  • 小步快跑:每次提交保持小而完整
  • 快速反馈:构建+测试应在10分钟内完成
  • 修复优先:发现问题立即修复,而非继续提交新代码

持续交付(CD)#

持续交付是在持续集成的基础上,将经过测试的代码自动部署到预生产环境或类生产环境中。代码在任何时候都处于可部署状态,最终是否部署到生产环境由人工决策。

持续部署(CD)#

持续部署是持续交付的最高阶段,它将经过所有自动化测试的代码自动部署到生产环境中,无需人工干预。

三者区别
  • CI:自动构建+自动测试
  • 持续交付:CI + 自动部署到预生产环境 + 手动上线
  • 持续部署:CI + 全流程自动化上线

CI/CD的核心价值#

  1. 提高开发效率:自动化的构建和测试流程让开发人员从繁琐的重复工作中解放出来,专注于编写代码
  2. 提升软件质量:频繁的自动化测试能够尽早发现bug,降低修复成本
  3. 缩短交付周期:从代码提交到上线的时间从数周缩短到数小时甚至数分钟
  4. 降低部署风险:标准化的自动化部署流程减少了人为错误,同时支持快速回滚
  5. 增强团队协作:CI/CD促进了开发、测试和运维团队之间的沟通与协作,推动DevOps文化的落地

主流CI/CD实现方式#

目前主流的CI/CD实现方式可以分为两大类:托管式CI/CD服务和自托管式CI/CD平台。

托管式CI/CD服务#

托管式CI/CD服务由第三方提供商维护,用户无需关心基础设施的搭建和维护,只需要简单配置即可使用。这类服务通常与代码托管平台深度集成,使用起来非常方便。

自托管式CI/CD平台#

自托管式CI/CD平台需要用户自己在服务器上搭建和维护,具有更高的灵活性和定制性,适合对安全性和可控性要求较高的企业。

四大主流CI/CD工具详解#

1. Jenkins:CI/CD领域的”老大哥”#

Jenkins是目前最流行的开源CI/CD工具,拥有庞大的社区和丰富的插件生态系统。它几乎可以与任何工具和技术集成,支持各种复杂的构建和部署场景。

核心特点:

  • 完全开源免费
  • 超过1000个插件,支持几乎所有的开发语言和工具
  • 高度可定制,可以通过Pipeline as Code定义复杂的流水线
  • 支持分布式构建,可以将任务分发到多个节点执行
  • 强大的社区支持和丰富的文档资源

Jenkins Pipeline示例:

Jenkinsfile
pipeline {
agent any
environment {
DOCKER_REGISTRY = 'registry.example.com'
APP_NAME = 'my-app'
}
stages {
stage('代码检出') {
steps {
git branch: 'main', url: 'https://github.com/user/repo.git'
}
}
stage('构建') {
steps {
sh 'mvn clean package -DskipTests'
}
}
stage('单元测试') {
steps {
sh 'mvn test'
}
post {
always {
junit 'target/surefire-reports/*.xml'
}
}
}
stage('Docker构建') {
steps {
script {
docker.build("${DOCKER_REGISTRY}/${APP_NAME}:${BUILD_NUMBER}")
}
}
}
stage('部署到测试环境') {
steps {
sh """
kubectl set image deployment/${APP_NAME} \
${APP_NAME}=${DOCKER_REGISTRY}/${APP_NAME}:${BUILD_NUMBER} \
-n test
"""
}
}
}
post {
success {
echo '构建成功!'
}
failure {
echo '构建失败,请检查日志'
}
}
}

适用场景:

  • 对灵活性和定制性要求高的企业
  • 复杂的多语言、多平台项目
  • 需要与现有工具链深度集成的场景

局限性:

  • 需要自己搭建和维护服务器,运维成本较高
  • 界面相对老旧,用户体验不如现代工具
  • 插件管理复杂,过多的插件可能导致性能问题和兼容性问题

2. GitLab CI/CD:一体化DevOps平台#

GitLab不仅仅是一个代码托管平台,它还内置了强大的CI/CD功能,提供了从代码管理、问题跟踪、CI/CD到容器镜像仓库的完整DevOps解决方案。

核心特点:

  • 与GitLab代码仓库深度集成,无需额外配置
  • 使用YAML文件定义流水线,简单易用
  • 支持Docker和Kubernetes原生集成
  • 提供自托管和SaaS两种版本
  • 内置代码质量检查、安全扫描等功能

GitLab CI配置示例:

.gitlab-ci.yml
stages:
- build
- test
- deploy
variables:
DOCKER_IMAGE: ${CI_REGISTRY_IMAGE}:${CI_COMMIT_REF_SLUG}
# 构建阶段
build:
stage: build
image: maven:3.8-openjdk-11
script:
- mvn clean package -DskipTests
artifacts:
paths:
- target/*.jar
expire_in: 1 hour
only:
- main
- develop
# 测试阶段
test:
stage: test
image: maven:3.8-openjdk-11
script:
- mvn test
coverage: '/Total.*?([0-9]{1,3})%/'
artifacts:
reports:
junit: target/surefire-reports/*.xml
# Docker构建
docker:build:
stage: build
image: docker:latest
services:
- docker:dind
script:
- docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
- docker build -t $DOCKER_IMAGE .
- docker push $DOCKER_IMAGE
only:
- main
# 部署到测试环境
deploy:test:
stage: deploy
image: bitnami/kubectl:latest
script:
- kubectl config use-context test-cluster
- kubectl set image deployment/myapp myapp=$DOCKER_IMAGE -n test
- kubectl rollout status deployment/myapp -n test
environment:
name: test
url: https://test.example.com
only:
- develop
# 部署到生产环境(需要手动触发)
deploy:prod:
stage: deploy
image: bitnami/kubectl:latest
script:
- kubectl config use-context prod-cluster
- kubectl set image deployment/myapp myapp=$DOCKER_IMAGE -n production
- kubectl rollout status deployment/myapp -n production
environment:
name: production
url: https://example.com
when: manual
only:
- main
GitLab CI注意事项
  • Runner需要足够的资源,特别是使用Docker-in-Docker时
  • 合理使用cache和artifacts避免重复构建
  • 生产环境部署建议使用when: manual手动触发

适用场景:

  • 已经在使用GitLab作为代码托管平台的团队
  • 希望使用一体化DevOps解决方案的企业
  • 容器化和云原生项目

局限性:

  • 自托管版本对服务器资源要求较高
  • 高级功能需要付费订阅
  • 灵活性不如Jenkins

3. GitHub Actions:GitHub原生CI/CD#

GitHub Actions是GitHub在2018年推出的CI/CD服务,它与GitHub平台深度集成,让开发者可以直接在GitHub仓库中自动化构建、测试和部署代码。

核心特点:

  • 与GitHub仓库无缝集成,无需额外账号
  • 拥有庞大的市场,提供大量预构建的Actions
  • 支持矩阵构建,可以同时在多个操作系统和平台上测试
  • 免费版提供一定的运行时间和存储空间
  • 支持Docker和Kubernetes部署

GitHub Actions工作流示例:

.github/workflows/ci-cd.yml
name: CI/CD Pipeline
on:
push:
branches: [ main, develop ]
pull_request:
branches: [ main ]
env:
REGISTRY: ghcr.io
IMAGE_NAME: ${{ github.repository }}
jobs:
build-and-test:
runs-on: ubuntu-latest
strategy:
matrix:
node-version: [14.x, 16.x, 18.x]
steps:
- uses: actions/checkout@v3
- name: 设置 Node.js ${{ matrix.node-version }}
uses: actions/setup-node@v3
with:
node-version: ${{ matrix.node-version }}
cache: 'npm'
- name: 安装依赖
run: npm ci
- name: 运行测试
run: npm test
- name: 代码覆盖率上传
uses: codecov/codecov-action@v3
if: matrix.node-version == '18.x'
docker-build:
needs: build-and-test
runs-on: ubuntu-latest
permissions:
contents: read
packages: write
steps:
- uses: actions/checkout@v3
- name: 登录到容器仓库
uses: docker/login-action@v2
with:
registry: ${{ env.REGISTRY }}
username: ${{ github.actor }}
password: ${{ secrets.GITHUB_TOKEN }}
- name: 提取元数据
id: meta
uses: docker/metadata-action@v4
with:
images: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}
- name: 构建并推送镜像
uses: docker/build-push-action@v4
with:
context: .
push: true
tags: ${{ steps.meta.outputs.tags }}
labels: ${{ steps.meta.outputs.labels }}
deploy:
needs: docker-build
runs-on: ubuntu-latest
if: github.ref == 'refs/heads/main'
steps:
- name: 部署到Kubernetes
uses: azure/k8s-deploy@v4
with:
manifests: |
k8s/deployment.yaml
k8s/service.yaml
images: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:latest
namespace: production
GitHub Actions最佳实践
  • 善用矩阵构建测试多个版本/平台
  • 使用actions/cache缓存依赖加速构建
  • 敏感信息存储在GitHub Secrets中
  • 合理使用needs控制作业依赖关系

适用场景:

  • 开源项目和个人开发者
  • 已经在使用GitHub作为代码托管平台的团队
  • 简单到中等复杂度的项目

局限性:

  • 免费版有运行时间和并发数限制
  • 复杂场景下的灵活性不如Jenkins
  • 自托管Runner需要自己维护

4. Gitee Actions:国产CI/CD的代表#

Gitee Actions是国产代码托管平台Gitee推出的CI/CD服务,它为国内开发者提供了更快的访问速度和更好的本地化支持。

核心特点:

  • 国内服务器,访问速度快,延迟低
  • 与Gitee平台深度集成
  • 兼容GitHub Actions的大部分语法和Actions
  • 免费版提供较为generous的运行时间
  • 支持国内云服务厂商的部署

适用场景:

  • 国内开发者和企业
  • 主要面向国内用户的项目
  • 希望避免国际网络延迟的团队

局限性:

  • 生态系统不如GitHub Actions丰富
  • 高级功能相对较少
  • 社区活跃度不如其他工具

工具对比与选型建议#

特性JenkinsGitLab CI/CDGitHub ActionsGitee Actions
部署方式自托管自托管/SaaSSaaS/自托管RunnerSaaS/自托管Runner
开源是核心开源否否
与代码平台集成需要插件原生原生原生
流水线定义Jenkinsfile(Groovy).gitlab-ci.yml(YAML)YAMLYAML
生态系统最丰富丰富非常丰富一般
国内访问速度取决于服务器取决于服务器较慢快
免费额度完全免费核心功能免费2000分钟/月2000分钟/月
学习曲线陡峭中等平缓平缓
灵活性最高高中等中等
选型建议
  • 个人/小团队 + GitHub → GitHub Actions
  • 国内团队 + Gitee → Gitee Actions
  • 需要一体化DevOps → GitLab CI/CD
  • 复杂场景 + 高定制需求 → Jenkins

总结#

CI/CD已经成为现代软件开发不可或缺的一环。选择合适的工具,建立高效的流水线,能够显著提升团队的开发效率和软件质量。无论选择哪种工具,核心都是要建立自动化、标准化的交付流程,让代码从提交到上线的每一步都可追溯、可重复、可回滚。

记住:好的CI/CD不是一蹴而就的,而是在实践中不断优化和完善的过程。从简单的自动化构建开始,逐步引入自动化测试、自动化部署,最终实现持续交付甚至持续部署,这是一个循序渐进的旅程。

CI/CD 从入门到精通:现代运维的核心引擎
https://www.6ixblog.site/posts/linux-swarm-1-1/
作者
Licwic
发布于
2026-05-01
许可协议
CC BY-NC-SA 4.0