DevOps 的文化理念
向 DevOps 的过渡需要文化理念和心态上的转变。简单来说，DevOps 的宗旨就是消除两个传统上孤立的团队（开发团队和运营团队）之间的壁垒。有些组织甚至没有独立的开发团队和运营团队，工程师可能身兼两职。利用 DevOps，这两个团队可以携手合作，共同提高开发人员的生产力，同时增强运营的可靠性。他们力求频繁沟通、提高效率，并改善客户服务的质量。他们能够完全掌控自己的服务，并且经常越过自己的既定角色或职能的传统工作范畴，思考最终用户的需求以及解决这些需求。质保和安全团队也可以与这两个团队紧密协作。凡是采用 DevOps 模式的组织，无论组织结构如何，参与团队都会将整个开发和基础设施生命周期视为己任。
DevOps 实践经验
有一些重要的实践经验能够通过自动实施和简化软件开发与基础设施管理流程，帮助组织加快创新速度。这些实践经验有大部分需要通过适当的工具来完成。
其中一个基本实践经验就是要频繁地进行小规模更新。这是组织能为客户快速提供创新的有效方式。与传统发布实践中偶尔的更新相比，这种更新通常更具渐进性质。频繁的小规模更新能够降低每次部署的风险。它们可以帮助团队更快速地处理错误，因为团队能够确定引发错误的最近一次部署。虽然更新的节奏和规模可能有所不同，但使用 DevOps 模式的组织与使用传统软件部署实践的组织相比，会更频繁更新。
此外，组织还可以使用微服务架构来提升应用程序的灵活性，从而加快创新步伐。微服务架构将大型的复杂系统拆分为简单的独立项目。应用程序被拆分为许多单个组件（服务），每个服务限定到单个目的或功能，这些服务既可以与其同级服务相互独立运行，也可以与应用程序一起作为整体运行。这种架构降低了更新应用程序的协调开销，当每个服务都与掌控各项服务的敏捷小型团队一一对应时，组织就可以实现更快的发展。
但是，微服务与较高的发布频率相结合会导致部署量大幅度增加，可能会带来运营挑战。因此，持续集成和持续交付等 DevOps 实践经验有助于解决这些问题，让组织能够以安全可靠的方式快速交付。与基础设施即代码和配置管理一样，基础设施自动化实践经验也有助于维持计算资源的弹性和对频繁变更的适应性。此外，进行监控和记录这一实践经验可帮助工程师追踪应用程序和基础设施的性能，以便他们快速应对出现的问题。
综合采用上述实践经验，可以帮助组织向客户更快交付更可靠的更新。对重要 DevOps 实践经验的简要介绍如下。
继续集成
持续集成是一种软件开发实践经验，采用持续集成时，开发人员会定期将他们的代码变更合并到一个中央存储库中，之后系统会自动运行构建和测试操作。持续集成的主要目标是更快发现并解决错误，提高软件质量，并缩短验证和发布新软件更新所需的时间。
持续交付
持续交付是一种软件开发实践经验，采用持续交付时，系统会对代码变更自动进行构建和测试，并为发布到生产环境做好准备。持续交付可以在构建阶段后将所有代码变更都部署到测试环境和/或生产环境中，从而实现对持续集成的扩展。当持续交付得以正确实施时，开发人员将始终能够获得一个已通过标准化测试流程的部署就绪型构建工件。
微服务
微服务架构是一种将单个应用程序构建为一系列小服务的设计方法。其中每个服务均按各自的流程运行，并利用一种轻型机制（通常为基于 HTTP 的应用程序编程接口 (API)）通过一个明确定义的接口与其他服务进行通信。微服务围绕着业务能力进行构建，每项服务均限定到单个目的。您可以使用不同的框架或编程语言来编写微服务，并将其作为单个服务或一组服务进行独立部署。
基础设施即代码
基础设施即代码是一种实践经验，其中基础设施通过代码和软件部署技术（例如版本控制和持续集成）得以预置和管理。借助云的 API 驱动型模式，开发人员和系统管理员能够以编程方式与基础设施进行大规模互动，而无需手动设置和配置资源。因此，工程师可以使用基于代码的工具来连接基础设施，并且能够以处理应用程序代码的方式来处理基础设施。基础设施和服务器由代码进行定义，因此可以使用标准化模式进行快速部署、使用最新补丁和版本进行更新，或者以可重复的方式进行复制。
