持续交付与 DevOps 体系

文章目录

[一. 开发模式演进：从传统到敏捷](#一. 开发模式演进：从传统到敏捷)
- [1. 传统开发流程](#1. 传统开发流程)
- [2. 敏捷开发体系](#2. 敏捷开发体系)
[二. 持续集成（CI）：代码质量的守门员](#二. 持续集成（CI）：代码质量的守门员)
- [1. GitLab CI 流程](#1. GitLab CI 流程)
[三. 持续交付（CD）：随时可发布的状态](#三. 持续交付（CD）：随时可发布的状态)
- [1. GitLab CD 流程](#1. GitLab CD 流程)
[四. 持续部署：全自动化的终极形态](#四. 持续部署：全自动化的终极形态)
[六. 核心概念对比：CI、CD 与持续部署](#六. 核心概念对比：CI、CD 与持续部署)
[七. DevOps 体系与技能全景](#七. DevOps 体系与技能全景)
- [1. 核心支柱](#1. 核心支柱)
- [2. 无限循环生命周期](#2. 无限循环生命周期)
- [3. DevOps 相关技能示例](#3. DevOps 相关技能示例)
[七. DevOps 中的左移与右移](#七. DevOps 中的左移与右移)

一. 开发模式演进：从传统到敏捷

1. 传统开发流程

模式特征：采用线性瀑布模式，依次经历分析（Analysis）、需求（Requirements）、设计（Design）、编码（Coding）、测试（Testing）和交付（End Game）六个阶段。
痛点：各阶段割裂，依赖接力棒式的任务传递，缺乏实时反馈，导致交付周期长且风险后置。

2. 敏捷开发体系

核心理念：围绕"价值流（Value Stream）"构建端到端流程，强调业务、开发、测试、运维角色的紧密协作。
- 一句话理解：价值就是客户想要的结果。以这个结果为导向，在明确目标后，业务方与开发、测试、运维团队紧密对齐 ，通过敏捷迭代的方式进行阶段性开发、测试与部署。这种模式打破了传统瀑布流的僵化壁垒，实现了更灵活、高效的端到端价值交付。
架构支撑：以敏捷为基础，通过持续集成（CI）支撑 DevOps，最终实现持续交付（Continuous Delivery），利用自动化齿轮（工具链）加速商业价值变现。

二. 持续集成（CI）：代码质量的守门员

1. 核心定义与运作机制

持续集成是一种 DevOps 软件开发实践。在这种模式下，开发人员会定期将代码变更合并到中央存储库中，随后系统会自动触发构建和测试操作。
2. 组成部分

持续集成不仅是一个技术流程（通常对应软件发布流程的构建或集成阶段），它还包含两个关键组成部分：
- 自动化组件：如 CI 服务或构建服务。
- 文化组件：要求团队养成频繁集成的习惯与文化。
3. 核心目标与价值
1. 更快地发现并解决软件缺陷。
2. 提升整体软件质量。
3. 缩短验证和发布新软件更新所需的周期时间。

持续集成是一种 DevOps 软件开发实践。采用持续集成时，开发人员会定期将代码变更合并到一个中央存储库中，之后系统会自动运行构建和测试操作。持续集成通常是指软件发布流程的构建或集成阶段，需要用到自动化组件（例如 CI 或构建服务）和文化组件（例如学习频繁地集成）。持续集成的主要目标是更快发现并解决缺陷，提高软件质量，并减少验证和发布新软件更新所需的时间。

定义：开发人员定期将代码变更合并到中央仓库，系统自动触发构建和测试。
目标：快速发现并修复缺陷，提高软件质量，缩短验证时间。

1. GitLab CI 流程

开发侧流程：创建分支 -> 推送代码变更（Push） -> 触发自动化构建与测试。
自动化测试持续集成（Jenkins）：代码检查 -> 自动构建 -> 自动测试（单元/集成） -> 结果反馈（Result）
反馈机制：若测试失败，立即通知开发者修复；若通过，则生成可部署构件。

三. 持续交付（CD）：随时可发布的状态

核心定义与目标：

持续交付是一种现代软件开发实践，旨在通过自动化流程，使系统始终处于"随时可发布到生产环境"的状态。它是对持续集成（CI）的扩展，在代码构建后自动将其部署到测试或生产环境中。
核心机制与状态 ：

在正确实施持续交付的情况下，开发团队始终掌握着"部署就绪"的构建构件。这些构件已经通过了标准化的测试流程，具备了直接面向客户发布的条件。
多维度自动化验证

持续交付打破了仅依赖单元测试的局限，引入了更广泛的自动化测试体系。在代码最终部署到客户环境前，系统会自动执行包括 UI 测试、负载测试、集成测试以及 API 可靠性测试等在内的多种验证。
核心价值

通过这种全方位、多维度的自动化验证，开发人员能够更全面地评估应用程序更新的质量，从而抢先发现并解决潜在问题，降低发布风险。

1. GitLab CD 流程

多环境流转：代码通过 CI 后，依次自动部署至测试环境（Test） -> 预发布环境（Staging）。
人工卡点：在生产环境（Production）部署前设置"人工审批"节点，确认无误后手动发布。
反馈回路：各环境（Test/Staging/Production）的执行结果均反馈给开发者，形成多层级质量门禁。

四. 持续部署：全自动化的终极形态

通过持续部署，可自动完成从代码提交到生产的全过程。开发与交付阶段之间的触发器是自动的，因此，在代码更改获得验证并通过所有测试后，就会立即发布。这意味着在改进功能可用后客户便可立即获得这些功能。

定义与特征

定义：代码通过所有验证后，自动发布到生产环境，无需人工干预。

核心价值：功能改进完成后客户可立即获得，实现极致的交付速度。

持续集成与持续交付
- 持续交付流水线
持续集成、持续交付、持续部署

六. 核心概念对比：CI、CD 与持续部署

维度	持续集成 (CI)	持续交付 (CD)	持续部署 (Continuous Deployment)
核心范围	代码合并、构建、单元测试	CI + 自动部署到预发布环境	CD + 自动部署到生产环境
人工干预	无	生产环境需人工审批	无
发布频率	频繁集成	按需发布	实时发布
风险控制	快速发现代码缺陷	人工卡点控制发布风险	依赖自动化测试覆盖率

七. DevOps 体系与技能全景

1. 核心支柱

持续集成/交付：自动化流水线基础。
微服务：架构解耦，独立部署。
基础设施即代码（IaC）：环境标准化。
监控与日志：全链路可观测性。
沟通协作：打破部门沟通壁垒。

2. 无限循环生命周期

左侧（Dev）：计划（Plan） -> 编码（Code） -> 构建（Build） -> 测试（Test）。
右侧（Ops）：发布（Release） -> 部署（Deploy） -> 运维（Operate） -> 监控（Monitor）。
核心枢纽：持续反馈（Continuous Feedback）连接开发与运维，驱动持续改进。

3. DevOps 相关技能示例

计划/编码：JIRA、Confluence、Git。
构建/测试：Maven、Sbt、Selenium、JUnit、Jenkins。
部署/运维：Docker、Kubernetes、AWS、Ansible、Chef。
监控：Nagios、Splunk、Datadog。

七. DevOps 中的左移与右移

1. 左移（Shift Left）
- 定义：在开发早期（计划、编码、构建阶段）引入测试与质量验证。
- 目的：确保软件符合设计，尽早发现缺陷，降低修复成本。
1. 右移（Shift Right）
- 定义：将监控、性能测试、可靠性验证延伸至生产环境（运维阶段）。
- 目的：确保系统在实际运行中的性能、弹性与可靠性，通过真实用户反馈优化产品。