很多人把 CI/CD 和 DevOps 混为一谈，以为做了自动化部署就是"搞 DevOps"。这个理解是不完整的。本篇讲清楚两者的关系——DevOps 是文化理念，CI/CD 是支撑这种理念落地的核心工具实践。理解了这层关系，你才知道为什么有些团队买了 Jenkins 却仍然效率低下。

传统组织中，开发（Dev）和运维（Ops）是两个割裂的团队：

开发团队                         运维团队
┌──────────┐                    ┌──────────┐
│ 关注功能  │ ──── 扔过墙 ────→ │ 关注稳定  │
│ 追求速度  │ ←── 报故障 ──────  │ 追求不挂  │
│ "快上线"  │                    │ "别搞事"  │
└──────────┘                    └──────────┘
        ↑                              ↑
    "运维太保守"                  "开发写的代码太烂"

结果：开发拼命推功能上线，运维拼命挡，互相指责。

DevOps 不是某个工具或技术，而是一套

消除开发与运维之间的隔阂，实现快速、安全的软件交付

2009年，Flickr 的工程师 John Allspaw 和 Paul Hammond 做了一个演讲 "10+ Deploys Per Day: Dev and Ops Cooperation at Flickr"，被公认为 DevOps 运动的起点。他们的核心观点是：

开发和运维不应该是两个对立的团队，而应该是共同为业务目标负责的一个团队

| C | Culture | 文化 | 打破部门墙，共同负责 |

| A | Automation | 自动化 | 重复的事交给机器 |

| L | Lean | 精益 | 减少浪费，小批量快速交付 |

| M | Measurement | 度量 | 用数据驱动决策 |

| S | Sharing | 共享 | 知识、工具、责任共享 |

                    DevOps 实践体系
    ┌──────────────────────────────────────────┐
    │                                          │
    │  ┌─────────┐  ┌──────────┐  ┌────────┐  │
    │  │ 计划    │  │ 编码     │  │ 构建   │  │
    │  │ Plan    │→│ Code     │→│ Build  │  │
    │  └─────────┘  └──────────┘  └───┬────┘  │
    │                                  ↓       │
    │  ┌─────────┐  ┌──────────┐  ┌────────┐  │
    │  │ 监控    │  │ 运维     │  │ 测试   │  │
    │  │ Monitor │←│ Operate  │←│ Test   │  │
    │  └─────────┘  └──────────┘  └───┬────┘  │
    │                                  ↓       │
    │  ┌─────────┐  ┌──────────┐  ┌────────┐  │
    │  │ 反馈    │←│ 部署     │←│ 发布   │  │
    │  │ Feedback│  │ Deploy   │  │Release │  │
    │  └─────────┘  └──────────┘  └────────┘  │
    │                                          │
    │  CI/CD 覆盖范围：Build → Test → Release → Deploy
    └──────────────────────────────────────────┘

CI/CD 是 DevOps 实践中"构建到部署"这段链条的技术实现。它对应 CALMS 中的 

| CALMS | 实践领域 | 具体工具/技术 |

| Culture | 跨职能团队 | 无特定工具，靠组织设计 |

| Automation | CI/CD | Jenkins、GitLab CI、GitHub Actions |

| Automation | 基础设施即代码 | Terraform、Ansible、Helm |

| Automation | 容器化 | Docker、Kubernetes |

| Lean | 看板/流程管理 | Jira、Trello、GitLab Issue |

| Measurement | 监控告警 | Prometheus、Grafana |

| Measurement | 日志分析 | ELK、Loki |

| Sharing | 知识管理 | Confluence、Wiki、GitLab Wiki |

| Sharing | 代码共享 | Git、GitLab、GitHub |

1. 共同负责（Shared Responsibility）

传统模式：                    DevOps 模式：
开发写完代码就交付             开发对代码从编写到运行全权负责
运维负责让代码跑起来           运维提供平台和工具支撑开发自服务
出了问题互相推诿             出了问题一起复盘改进

2. 失败是学习机会（Blameless Culture）

传统模式：                    DevOps 模式：
"谁干的？追责！"              "为什么系统允许这个错误发生？"
找到"背锅侠"                 改进系统防止再次发生

传统模式：                    DevOps 模式：
"稳定压倒一切，别改"          "每周改进一点，积少成多"
大版本大改动                 小步快跑，持续优化

Google DORA（DevOps Research and Assessment）团队提出了一套衡量 DevOps 成熟度的标准指标：

| 指标 | 说明 | 精英团队 | 低效团队 |

| 变更前置时间 | 从提交到上线多久 | <1天 | 1-6个月 |

| 变更失败率 | 部署导致故障的比例 | 0-15% | 16-30% |

| 平均恢复时间 | 故障恢复速度 | <1小时 | >6个月 |

# GitLab CI 中收集流水线指标
stages:
  - build
  - test
  - deploy
  - metrics

collect-metrics:
  stage: metrics
  script:
    # 记录流水线执行时间
    - DURATION=$((CI_PIPELINE_DURATION / 1000))
    # 记录部署成功率
    - STATUS=$([ "$CI_PIPELINE_SOURCE" = "push" ] && echo "success" || echo "failed")
    # 推送到 Prometheus Pushgateway
    - |
      cat <<EOF | curl --data-binary @- http://pushgateway:9091/metrics/job/cicd
      cicd_pipeline_duration_seconds{branch="$CI_COMMIT_BRANCH"} $DURATION
      cicd_pipeline_status{branch="$CI_COMMIT_BRANCH",status="$STATUS"} 1
      EOF
  when: always  # 无论成功失败都收集

# Prometheus 告警规则：变更失败率过高
groups:
- name: cicd-alerts
  rules:
  - alert: HighDeploymentFailureRate
    expr: |
      sum(rate(cicd_pipeline_status{status="failed"}[1h]))
      /
      sum(rate(cicd_pipeline_status[1h]))
      > 0.2
    for: 30m
    labels:
      severity: warning
    annotations:
      summary: "部署失败率超过20%"

目标：让代码频繁安全地合并
      ↓
行动：
1. 选择代码托管平台（GitLab/GitHub）
2. 搭建 CI 工具
3. 编写基础流水线（构建+测试）
4. 建立代码审查流程
5. 度量：代码合并频率、构建成功率

阶段二：CD 持续交付（3-6个月）

目标：随时可发布
      ↓
行动：
1. 容器化应用（Docker）
2. 搭建制品仓库
3. 流水线扩展到自动部署测试环境
4. 建立预发环境
5. 度量：变更前置时间、部署到测试环境的耗时

阶段三：DevOps 全面落地（6-12个月）

目标：快速、安全、可度量
      ↓
行动：
1. 基础设施即代码（Terraform + Ansible）
2. 监控告警体系（Prometheus + Grafana）
3. 自动回滚与金丝雀发布
4. 混沌工程与故障演练
5. 度量：DORA 四指标全部达标

：CI/CD 入门篇收官，接下来进入 Jenkins 实战篇。我们从《环境搭建：从零部署 Jenkins 主从架构》开始，手把手带你搭建第一个 CI/CD 平台。

前言 很多人把 CI/CD 和 DevOps 混为一谈，以为做了自动化部署就是"搞 DevOps"。这个理解是不完整的。本篇讲清楚两者的关系——DevOps 是文化理念，CI/CD 是支撑这种理念落地的核心工具实践。理解了这层关系，你才知道为什么有些团队买了 Jenkins 却仍然效率低下。 一、DevOps 的起源与本质 痛点：开发与运维的"墙" 传统组织中，开发（Dev）和运维（Ops）是两个...

【CI/CD·入门篇】CI/CD与DevOps的关系：文化、工具与实践的融合

研发部经理

人工智能

DevOps是文化理念，CI/CD是其核心自动化实践。本文解析DevOps本质、CALMS框架及DORA四指标，厘清两者关系，提供从CI基础到全面落地的三阶段路线图，助你避免“买了Jenkins仍低效”的误区。

基础设施即代码

日志分析

Kubernetes

Terraform

容器

DevOps

GitHub

2026上云采购 | AI焕新·智启新局

腾讯云BI特惠9.9元起！


文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

【CI/CD·入门篇】CI/CD与DevOps的关系：文化、工具与实践的融合

【CI/CD·入门篇】CI/CD与DevOps的关系：文化、工具与实践的融合

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐