DevOps 将开发（Dev）和运营（Ops）结合起来，将人员、流程和技术统一到应用程序规划、开发、交付和运营中。 DevOps 支持在以前孤立的角色（如开发、IT 运营、质量工程和安全）之间进行协调和协作。
Teams 采用 DevOps 文化、做法和工具，提高他们对所构建的应用程序的信心，更好地响应客户需求，并更快地实现业务目标。 DevOps 通过生产更好、更可靠的产品，帮助团队不断为客户提供价值。
DevOps 和应用程序生命周期
DevOps 在其规划、开发、交付和运营阶段影响应用程序生命周期。 每个阶段依赖于其他阶段，并且阶段不特定于角色。 DevOps 文化在某种程度上涉及到每个阶段中的所有角色。
下图说明了 DevOps 应用程序生活方式的阶段：
DevOps 目标和优势
当团队采用 DevOps 文化、实践和工具时，他们可以实现惊人的成就：
加快上市时间
通过提高效率、改进的团队协作、自动化工具和持续部署，团队能够快速减少从产品启动到市场推出的时间。
适应市场和竞争
DevOps 文化要求团队以客户为中心。 通过实现敏捷性、团队协作并专注于客户体验，团队可以持续为客户提供价值，并提高其在市场中的竞争力。
维护系统稳定性和可靠性
通过采用持续改进做法，团队能够增强部署的产品和服务的稳定性和可靠性。 这些做法有助于降低故障和风险。
缩短恢复的平均时间
恢复指标的平均时间指示从故障或违规中恢复所需的时间。 若要管理软件故障、安全漏洞和持续改进计划，团队应衡量并努力改进此指标。
采用 DevOps 文化
要全面实施 DevOps，必须采用 DevOps 文化。 培养 DevOps 文化需要人们工作和协作的方式发生深刻变化。 当组织致力于 DevOps 文化时，他们会为高性能团队创建一个环境来发展。 虽然采用 DevOps 实践通过技术自动化和优化流程，但如果不在组织及其成员内部转变为 DevOps 文化，就无法获得 DevOps 的全部优势。
下图捕获了Microsoft在线动态文化的关键方面。
以下做法是 DevOps 文化的关键组成部分：
- 协作、可见性和一致性：健康的 DevOps 文化的标志是团队之间的协作。 协作从可见性开始。 开发、IT 和其他团队应相互共享其 DevOps 流程、优先级和关注点。 通过共同规划工作，他们更有能力在与业务相关的目标和成功措施上保持一致。
- 范围和责任的转变：随着团队的协调一致，他们承担责任并参与到其他生命周期阶段，而不仅仅是他们核心职责涉及的阶段。 例如，开发人员不仅对开发阶段建立的创新和质量负责，而且要追究其变化带来的运营阶段的性能和稳定性。 同时，IT 操作员肯定会在计划和开发阶段包括治理、安全性和合规性。
- 较短的发布周期：DevOps 团队通过在短周期中发布软件来保持敏捷性。 较短的发布周期使规划和风险管理更容易，因为进度是增量的，这也降低了对系统稳定性的影响。 缩短发布周期还使组织能够适应和应对不断变化的客户需求和竞争压力。
- 持续学习：高性能 DevOps 团队建立成长型思维模式。 他们迅速试错并将经验教训融入其流程。 他们努力不断提高、提高客户满意度，加快创新和市场适应性。
实现 DevOps 做法
在整个应用程序生命周期中，通过遵循 DevOps 实践（以下各节中所述）来实现 DevOps。 其中一些做法有助于加速、自动化和改进特定阶段。 其他因素跨越多个阶段，帮助团队创建无缝流程，从而提高生产力。
持续集成和持续交付 (CI/CD)
持续集成（CI）是开发团队用来自动执行、合并和测试代码的做法。 CI 有助于在开发周期的早期捕获 bug，从而使这些 bug 的修复成本更低。 自动测试作为 CI 过程的一部分执行，以确保质量。 CI 系统生成制品并将其馈送给发布过程，以驱动频繁的部署。
持续交付（CD）是一个通过构建、测试和部署代码到一个或多个测试和生产环境的过程。 在多个环境中部署和测试可以提高质量。 CD 系统生成可部署的项目，包括基础结构和应用。 自动发布过程使用这些项目来发布新版本，并修复现有系统。 监视和发送警报的系统会持续运行，以推动整个 CD 过程的可见性。
版本控制
版本控制是管理版本中的代码的做法-跟踪修订和更改历史记录，使代码易于查看和恢复。 这种做法通常使用 Git 等版本控制系统来实现，这允许多个开发人员在创作代码中协作。 这些系统提供了一个明确的过程，用于合并在同一文件中发生的代码更改、处理冲突以及将状态回滚到早期版本。
使用版本控制是一项基本的 DevOps 实践，可帮助开发团队协同工作，在团队成员之间划分编码任务，并存储所有代码，以便在需要时轻松恢复。 版本控制也是其他做法（如持续集成和基础结构即代码）中的必要元素。
敏捷软件开发
敏捷是一种软件开发方法，强调团队协作、客户和用户反馈，以及通过短发布周期进行更改的高适应性。 实践敏捷的团队为客户提供持续的变化和改进，收集反馈，然后根据客户需求和需求学习和调整。 敏捷与瀑布模型等其他更传统的框架大相径庭，后者包括按顺序阶段定义的长发布周期。 看板和 Scrum 是两个与敏捷相关的常用框架。
基础结构即代码
基础结构即代码以描述性的方式定义系统资源和拓扑，使团队能够像编写代码一样管理这些资源。 这些定义也可以在版本控制系统中存储和版本控制，可以在其中再次查看和还原它们，就像代码一样。
练习基础结构即代码可帮助团队以可靠、可重复和控制的方式部署系统资源。 基础结构即代码还有助于自动部署并降低人为错误的风险，尤其是对于复杂的大型环境。 这种可重复的可靠环境部署解决方案使团队能够维护与生产相同的开发和测试环境。 将环境复制到不同的数据中心和云平台同样变得更加简单且更高效。
配置管理
配置管理是指管理系统中资源的状态，包括服务器、虚拟机和数据库。 使用配置管理工具，团队可以采用受控、系统的方式推出更改，从而降低修改系统配置的风险。 Teams 使用配置管理工具跟踪系统状态并帮助避免配置偏移，这就是系统资源的配置随时间推移而偏离为其定义的所需状态的方式。
除了基础结构即代码之外，可以轻松模板化和自动化系统定义和配置，从而帮助团队大规模运行复杂的环境。
持续监视
持续监视意味着能够全面实时地了解整个应用程序堆栈的性能和运行状况。 此可见性范围从运行应用程序的基础基础结构到更高级别的软件组件。 可见性是通过收集遥测和元数据以及预定义条件设置警报来实现的，这些条件需要操作员注意。 遥测包括从系统的各个部分收集的事件数据和日志，这些日志存储在可以分析和查询的位置。
高性能 DevOps 团队可确保他们设置可作、有意义的警报并收集丰富的遥测数据，以便他们可以从大量数据中获取见解。 这些见解可帮助团队实时缓解问题，并了解如何在未来的开发周期中改进应用程序。
Planning
在规划阶段，DevOps 团队会思考、定义和描述他们计划生成的应用程序和系统的特性和功能。 团队从单个产品到多个产品系列，以不同细化程度跟踪任务进度。 Teams 使用以下 DevOps 实践来运用 敏捷性和可见性进行规划：
有关为支持公司软件团队中的 DevOps 规划而采用的若干经验教训以及 Microsoft 采用的做法的概述，请参阅 Microsoft 如何进行 DevOps 规划。
开发
开发阶段包括开发软件代码的所有方面。 在此阶段，DevOps 团队执行以下任务：
为了在不牺牲质量、稳定性和工作效率的情况下快速创新，DevOps 团队：
有关 Microsoft 为实现向 DevOps 转型而采用的开发实践概况，请参阅 Microsoft 如何开发利用 DevOps。
交付
交付是一致且可靠地将应用程序部署到生产环境的过程，最好是通过 持续交付（CD）进行。
在交付阶段，DevOps 团队：
- 使用明确的手动审批阶段定义发布管理过程。
- 设置自动入口，在阶段之间移动应用程序，直到最终发布给客户。
- 自动执行交付过程，使其可缩放、可重复、受控和 经过良好测试。
交付还包括部署和配置交付环境的基础基础结构。 DevOps 团队使用 基础结构即代码（IaC）、 容器和 微服务 等技术来提供完全治理的基础结构环境。
在影响客户体验之前，安全部署做法可以识别问题。 这些做法可帮助 DevOps 团队轻松、自信和安心地频繁交付。
Microsoft 演变出核心 DevOps 原则和流程以提供高效的交付系统，这些内容在Microsoft 如何使用 DevOps 交付软件中有详细描述。
Operations
作阶段涉及在生产环境中维护、 监视和故障排除应用程序，包括混合云或公有云（例如 Azure）。 DevOps 团队旨在实现系统可靠性、高可用性、强大的安全性和零停机时间。
自动化交付和安全部署做法可帮助团队在出现问题时快速识别和缓解问题。 保持警惕需要丰富的遥测、可作的警报和对应用程序和基础系统的完全可见性。
Microsoft 用于操作复杂在线平台的做法在如何使用 DevOps 运行可靠系统中进行了描述。