什么是 DevOps 生命周期？

DevOps 流程描述了软件如何从构思开始，经过生产和反馈，再回到构思的过程，开发和运维团队作为一个协同的整体共同工作。它包含一系列端到端的实践和自动化工作流，DevOps 团队可以使用这些来规划、开发、运行和优化软件发布。

DevOps 生命周期的各个阶段通常被描绘为“无限循环”的一部分，开发活动在左侧，运维活动在右侧，通过一条连续的路径连接起来。

在循环的“计划 → 编码 → 构建 → 测试”一侧，团队将软件需求细化为小的用户故事，增量地（但频繁地）提交代码到代码仓库，并使用持续集成 (CI) 工具自动构建和测试每个代码变更。

在“发布 → 部署 → 运维 → 监控”一侧，自动化工作流将变更推送到 IT 环境并交付给用户。同时， 可观测性工具跟踪系统运行状况、软件性能和用户行为，检测问题并衡量整体影响。

无限循环强调了 DevOps 生命周期的每个阶段都会相互影响。团队共享工作、知识和责任，而不是在孤岛之间来回传递。该循环也说明了 DevOps 工作流如何简化软件交付和优化流程。理想情况下，每个周期都比上一个更快、更安全、更自动化。

因此，DevOps 生命周期使企业能够协调人员、流程和工具，以交付高质量的软件应用程序和无摩擦的用户体验。

DevOps 生命周期的每个阶段都与其他阶段相互联系并有所重叠，但每个阶段都有明确的目的和一系列相关活动。这些阶段包括：

在规划阶段，DevOps 团队将业务需求和用户反馈转化为清晰、优先、有时限的工作计划和项目管理流程，用于指导后续阶段中的开发和运维活动。此阶段明确了软件发布或系统构建的愿景、范围和路线图，以便每个人都了解他们正在构建什么、为什么重要以及他们将如何衡量成功。

典型的规划活动可能包括：

• 梳理产品待办事项列表（如新功能、错误修复和技术债务）并进行分类。

• 分析利益相关者的输入，获取用户需求和约束条件。

• 将工作分解为任务、用户故事（从用户角度编写的软件功能描述）和史诗（过于庞大无法在单个软件迭代中处理的用户故事），估算资源需求并识别依赖关系。

• 定义关键绩效指标 (KPI)、服务水平指标 (SLI) 和服务水平目标，以便后续阶段知晓“好”的标准是什么。

在编码阶段，开发者将规划好的基础设施和软件需求转化为可工作的源代码，并着眼于质量保证和未来运维。这不仅仅是编写新代码。还要为后续管道中的自动化构建、测试、集成和部署流程设置所有必要的组件。

编码过程包括：

• 编写代码以实现新功能、修复缺陷并处理非功能性需求（例如安全性）。

• 将小而增量的代码变更提交到版本控制系统（如 Git 和 GitHub）内的共享仓库以供审查。

• 测试代码提交，使其能够无缝构建并与代码库集成。

• 添加或更新自动化单元测试和组件测试，以便未来的持续集成运行能够在每次提交后自动验证代码行为。

在构建阶段，源代码变更被自动编译、验证并打包成可部署的构建产物。DevOps 工具从版本控制系统获取代码变更，运行自动化检查，并生成已版本化、准备部署或进一步测试的软件包（例如 Docker 容器镜像和编译后的二进制文件）。

更具体地说：

• 自动化脚本和构建工具编译源代码，解析并下载依赖项（包括库、框架和模块），并将所有内容链接成可执行文件或镜像。

• 基本的自动化测试作为构建的一部分运行。如果构建失败，则标记为损坏，并停留在构建阶段。如果构建通过，则进入生命周期的下一个阶段。

测试阶段（也称为验证阶段）旨在确保代码变更在真实条件下按预期运行。DevOps 团队使用一系列高级测试工具，在每个变更进入管道更深处或到达生产环境之前，持续验证其功能、安全性和性能。

通常，测试流程紧密集成到持续集成/持续交付 (CI/CD) 管道中，以便开发人员获得关于代码质量的快速、频繁反馈。

软件测试的主要目标是尽早识别缺陷（此时修复成本更低、更容易），并防止有缺陷的构建进入发布流程。测试还验证新的变更不会破坏现有功能，帮助开发者在软件产品演进过程中维护整体系统稳定性。

发布阶段在“已测试的构建”和“实时部署”之间提供了受控的门户，在此阶段，代码变更被批准用于生产，并对目标用户可见。开发团队通过打包已验证、测试通过的代码、确认其已为生产环境就绪，并协调其进入预发布环境和生产环境的方式和时间，为部署做好准备。

常见的发布流程包括：

• 根据预定义的验收标准进行最终的质量、安全和合规性检查。

• 将构建产物附加到特定的发布版本，并创建变更日志和文档。

• 识别即将发布的版本中的漏洞，并规划缓解策略（例如回滚）以解决问题。

在部署阶段，经过测试和打包的代码被自动交付到目标环境（预发布或生产）。配置管理和基础设施即代码 (IaC) 工具——它们使用配置文件和高级描述性编程语言来自动化软件发布的基础设施配置 和编排——帮助 DevOps 团队确保以可靠、可重复的方式交付软件。

部署通常由 持续交付 (CD) 和容器化平台（例如 Kubernetes）驱动，这些平台编排软件部署过程（拉取构建产物、更新容器和二进制文件、运行最终测试以及将流量切换到新版本）。

DevOps 团队经常使用不同的部署策略来确保新版本逐步引入，并在必要时能够快速回滚。

例如，通过蓝绿部署，应用程序被部署到两个并行的生产环境中，每个环境运行该应用的不同版本。“蓝”环境运行实时应用程序，而“绿”环境则处理新应用版本的测试和验证。当新迭代通过验证后，绿环境成为实时环境，而蓝环境保持空闲——但可用——以处理回滚。

通过金丝雀部署，团队先将应用程序部署给一小部分用户（即“金丝雀”），用于在真实环境中监控和测试，然后再将应用推广到整个用户群。

就像金丝雀曾被用来警告煤矿工人有毒气体一样，金丝雀部署也能警告开发团队应用程序的缺陷，而不会冒影响所有用户的大规模性能问题的风险。如果应用程序在金丝雀组中表现良好，开发人员会逐步将其推广到更大的群体，直到所有用户都能使用。

运维阶段专注于在生产环境中，在真实工作负载下，保持实时系统的稳定、高性能、安全且可供真实用户使用。这并非应用程序生命周期的“终点”。相反，它向更早的阶段反馈数据和洞察。

在此阶段，DevOps 团队：

• 在生产环境中运行和监督应用程序，包括所有相关的基础设施、服务和依赖项。

• 管理容量规划和扩缩容流程，以确保流量不会随时间推移而降级。

• 检测问题并进行分类，处理性能瓶颈，并根据需要应用错误修复或回滚。

• 应用安全补丁并执行治理实践（如访问控制和合规性审计），优化系统安全性。

在监控阶段，团队持续观察生产环境中的应用程序和基础设施，检测问题、了解真实用户行为，并将洞察反馈给开发和运维部门。

DevOps 团队从应用程序、服务器、网络和数据库收集可观测性数据（指标、日志和追踪）以及其他信息，以实时跟踪性能。他们设置阈值和警报，以便异常情况（如 API 高延迟或可疑的访问模式）触发通知，以便快速调查和修复。

如果监控工具发现软件缺陷或可用性问题，它们会将信息转发给问题追踪器和待办事项列表，以便团队调整后续迭代。​

无限循环并没有明确包含“安全”阶段，但 DevOps 管道通常涉及将安全措施贯穿整个生命周期的实践和技术。

这就是 DevSecOps 融入该框架的方式。

DevSecOps（开发、安全与运维的缩写）是一种软件开发实践，它将安全协议从开发生命周期的右侧（末端）转移到左侧（开始）。通过左移，开发者在编写代码时就实施安全协议（如数据加密、输入验证、基于角色的访问控制和多重身份验证）。

DevSecOps 也包含“右移”活动，将安全实践扩展到部署后的生产环境。右移实践优先考虑在真实条件下对运行时应用程序进行监控、测试和保护。它们通过创建一个持续的反馈循环来补充左移安全，即生产中发现的安全问题能够反馈到更早的开发阶段。

左移和右移安全结合使用，使企业能够将安全控制集成到 DevOps 生命周期的每个阶段。这种双重的、“全面转移”的安全策略帮助 DevOps 团队同时实现早期预防和部署后的威胁检测与响应，从而增强整体安全态势并推动持续改进。

DevOps 生命周期代表了更传统的软件开发方法（如瀑布模型和敏捷开发）的演进。

瀑布模型是一种遵循线性、顺序流程的开发方法，生命周期中的每个阶段——需求收集、设计、实施、测试、部署和维护——都必须完全完成并获得批准后，下一个阶段才能开始。它强调主动规划、详细文档和可预测性，使其适用于需求稳定、定义明确且预期变更较少的项目（例如政府、医疗相关项目）。

瀑布模型提供了强大的流程控制，但开发团队是孤立的。在一个阶段完成后进行修改成本高且耗时长。简而言之，瀑布模型难以适应敏捷性要求。

敏捷开发是一种迭代式的开发方法，通过短周期（称为“冲刺”）交付小而可工作的功能增量。它强调基于利益相关者反馈的自适应规划、早期交付和持续改进，使开发团队能够快速响应不断变化的需求和条件。

敏捷方法在动态环境（例如初创公司）中被证明是有效的。它通过跨职能团队（优先考虑软件功能而非全面文档）来缓解瀑布方法的线性僵化问题。然而，敏捷方法专注于软件开发过程，将运维过程排除在外。 

DevOps 提供了一种现代的、融合了开发与运维团队的文化和技术实践，利用 CI/CD工具（如 GitLab）实现测试、部署和监控的自动化。与敏捷和瀑布不同，DevOps 实践可以帮助企业加速软件发布，并构建在当今高度动态的微服务架构和基于云的 IT 环境中保持高性能和敏捷性的应用程序。

7C 提供了另一种将 DevOps 生命周期概念化为七个持续过程产物的方式。

持续开发涉及软件的规划和编码，开发人员将过程分解为更小、更易于管理的迭代。开发者将变更存储在版本控制系统中，并使其代码持续与利益相关者需求保持一致，帮助团队最小化风险并快速适应变化。

持续集成将来自多个开发者的代码变更合并到一个共享仓库中，并在每次提交后自动触发构建。它使 DevOps 团队能够持续改进其软件应用程序，接收持续的反馈，在错误影响软件性能之前捕获并修复它们，并以更可预测的时间表交付更高质量的软件。

持续测试使开发者能够自动启动代码审查和测试协议（例如 单元测试）。它使用测试工具持续检查集成后的代码是否存在错误、可用性缺陷和性能问题。持续测试为开发者提供所需的快速反馈，改进软件而不延误生命周期。

持续交付自动将应用程序和经过验证的代码库变更（更新、错误修复甚至新功能）交付到所有必要的基础设施环境，供进一步测试。通过所有集成测试和验证阶段的代码构建被打包并交付到代码仓库，该仓库集中存储处于可部署状态的代码包。

持续部署更进一步，自动将每个经批准的变更部署到生产环境，无需人工干预。当代码更新经过测试、验证和批准后，持续部署工具将软件制品移动到预生产预演环境或公共服务器和分发平台（例如应用商店），用户可以在这些地方访问它。

持续反馈要求 DevOps 团队从监控数据、用户体验数据和利益相关者的输入中收集洞察，以完善产品待办事项列表并确定每项改进的优先级。

持续监控实时跟踪应用程序和基础设施的性能，主动识别问题以维护系统可靠性。大多数监控工具通过仪表板可视化 CI/CD 管道数据，这提高了技术栈的可见性并支持数据驱动的优化。

自动化工具处理基础设施配置、资源扩缩、数据备份、流量路由和系统维护，使 DevOps 团队能够将反馈持续应用于新的应用程序迭代。

利用 DevOps 最佳实践可以为企业带来众多好处，包括：