DevOps通过结合软件开发和IT运营团队的工作并使之自动化，加快了更高质量软件的交付。
什么是DevOps？
根据定义，DevOps概述了一种软件开发流程和组织文化的转变，它通过自动化和整合开发和IT运营团队的工作来加速交付更高质量的软件—这两个团队在传统上是相互分离的，或者说是孤立的。
在实践中，最好的DevOps流程和文化超出了开发和运营的范围，将所有应用的利益相关者—包括平台和基础设施工程、安全、合规性、治理、风险管理、业务线、最终用户和客户—的投入纳入软件开发的生命周期。
DevOps代表了过去20多年来软件交付周期演变的现状，从每隔几个月甚至几年发布一次巨大的应用范围内的代码，到每天或每天发布数次的迭代性较小的特征或功能更新。
归根结底，DevOps是为了满足软件用户对频繁的、创新的新功能以及不间断的性能和可用性日益增长的需求。
我们是如何走向DevOps的
直到2000年之前，大多数软件的开发和更新都是采用瀑布式方法，这是一种大规模开发项目的线性方法。软件开发团队会花几个月的时间来开发大量的新代码，这些代码影响到大部分或全部的应用程序。由于变化太大，他们又花了几个月的时间将新代码集成到代码库中。
接下来，质量保证（QA）、安全和运营团队将花费更多的时间来测试代码。其结果是，软件发布间隔数月甚至数年，而且在发布间隔中往往还有几个重要的补丁或错误修复。这种 “大爆炸 “式的功能交付方式的特点是：复杂而有风险的部署计划，难以安排与上游和下游系统的联动，以及IT部门 “非常希望 “业务需求在生产 “上线 “前的几个月内没有大的变化。
为了加快开发速度和提高质量，开发团队开始采用敏捷软件开发方法，这种方法是迭代式的，而不是线性的，重点是对应用程序代码库进行更小、更频繁的更新。这些方法学中最主要的是持续集成，或CI/CD。在CI/CD中，较小块的新代码每隔一到两周就被合并到代码库中，然后自动集成、测试并准备部署到生产环境中。敏捷将 “大爆炸 “的方法演变为一系列的 “小片段”，也将风险分割开来。
这些敏捷开发实践越是有效地加速了软件开发和交付，就越是暴露了仍然是孤军奋战的IT运营—系统配置、配置、验收测试、管理、监控—成为软件交付生命周期中的下一个瓶颈。
因此，DevOps从敏捷中发展出来。它增加了新的流程和工具，将CI/CD的持续迭代和自动化扩展到软件交付生命周期的其他部分。而且，它在流程的每一步都实现了开发和运营之间的紧密合作。
DevOps如何工作，DevOps的生命周期
DevOps生命周期（有时被称为持续交付管道，当以线性方式描述时）是一系列迭代的、自动化的开发过程或工作流，在一个更大的、自动化和迭代的开发生命周期内执行，旨在优化高质量软件的快速交付。工作流程的名称和数量取决于你问的人，但它们通常归结为这六个:
- 规划（或构思）。在这个工作流程中，团队从优先考虑的终端用户反馈和案例研究，以及所有内部利益相关者的投入中找出下一个版本的新特性和功能。规划阶段的目标是通过产生一个积压的功能，使产品的商业价值最大化，这些功能在交付时产生一个有价值的预期结果。
- 开发。这是编程步骤，开发人员根据用户故事和积压的工作项目，测试、编码和建立新的和增强的功能。测试驱动开发（TDD）、结对编程和同行代码审查等做法的组合是很常见的。开发人员经常使用他们的本地工作站来执行编写和测试代码的 “内循环”，然后将其发送到持续交付管道。
- 集成（或构建，或持续集成和持续交付（CI/CD）。如上所述，在这个工作流程中，新的代码被集成到现有的代码库中，然后测试并打包成可执行文件进行部署。常见的自动化活动包括将代码变化合并到一个 “主 “副本中，从源代码库中检查出该代码，并自动进行编译、单元测试和打包成可执行文件。最佳做法是将CI阶段的输出存储在一个二进制库中，供下一阶段使用。
- 部署（通常称为持续部署），在这里，运行时构建输出（来自集成）被部署到运行时环境中–通常是一个开发环境，在那里执行运行时测试以保证质量、合规性和安全性。如果发现错误或缺陷，开发人员有机会在任何终端用户看到之前拦截和补救任何问题。通常有开发、测试和生产环境，每个环境都需要逐步 “严格 “的质量关口。部署到生产环境的一个良好做法是，首先部署到最终用户的一个子集，一旦建立了稳定性，再最终部署到所有用户。
- 操作。如果把交付给生产环境的功能描述为 “第一天”，那么一旦功能在生产中运行，就会发生 “第二天 “的操作。监控功能的性能、行为和可用性，确保功能能够为终端用户提供增值服务。运营部门确保功能顺利运行，并确保服务没有中断—确保网络、存储、平台、计算和安全状况都是健康的！如果出现问题，运营部门会确保事件发生。如果出了问题，运营部门确保事件被识别，适当的人员被提醒，问题被确定，修复被应用。
- 学习（有时称为持续反馈）。这是从终端用户和客户那里收集关于特性、功能、性能和商业价值的反馈，以带回下一个版本的增强和特性规划。这也包括来自运营活动的任何学习和积压项目，这些项目可以使开发人员主动避免任何过去可能在未来再次发生的事件。这就是规划阶段的 “包装 “发生的地方，我们 “持续改进”。
在这些工作流程之间还有三个重要的连续工作流程。
持续测试。 经典的DevOps生命周期包括一个离散的 “测试 “阶段，发生在集成和部署之间。然而，DevOps的发展使得某些测试元素可以在计划（行为驱动开发）、开发（单元测试、合同测试）、集成（静态代码扫描、CVE扫描、刷新）、部署（烟雾测试、渗透测试、配置测试）、运营（混乱测试、合规性测试）和学习（A/B测试）中发生。测试是一种强大的风险和漏洞识别形式，为IT部门提供了接受、减轻或补救风险的机会。
安全性。当瀑布式方法和敏捷实施在交付或部署后 “附加 “安全工作流程时，DevOps努力从一开始（规划）就纳入安全问题—当安全问题最容易解决且成本最低时—并在开发周期的其余部分持续进行。这种安全方法被称为 “左移”（如果你看图1就更容易理解）。一些组织在左移方面的成功率低于其他组织，这导致了DevSecOps的崛起（见下文）。
合规性。合规性（治理和风险）也最好在早期和整个开发生命周期内解决。受监管的行业通常被要求提供一定程度的可观察性、可追踪性和可访问性，以了解功能如何在其运行时的操作环境中被交付和管理。这需要在持续交付管道和运行时环境中规划、开发、测试和执行政策。合规措施的可审计性对于向第三方审计人员证明合规性极为重要。
DevOps文化
人们普遍认为，如果没有对DevOps文化的承诺，DevOps方法就无法发挥作用，这可以概括为一种不同的软件开发的组织和技术方法。
在组织层面上，DevOps要求所有的软件交付利益相关者—软件开发和IT运营团队，以及安全、合规、治理、风险和业务线团队—之间进行持续的沟通、协作和分担责任，以便快速和持续地进行创新，并从一开始就将质量纳入软件。
在大多数情况下，实现这一目标的最佳方式是打破这些孤岛，并将其重组为跨职能、自主的DevOps团队，这些团队可以自始至终地从事代码项目—从计划到反馈—而无需向其他团队交接或等待批准。当放在敏捷开发的背景下，共同的责任和协作是拥有一个共同的产品焦点的基石，有价值的结果。
在技术层面上，DevOps需要对自动化作出承诺，使项目在工作流程内和工作流程之间不断前进，并对反馈和测量作出承诺，使团队能够不断地加快周期，提高软件质量和性能。
DevOps工具，构建一个DevOps工具链
DevOps和DevOps文化的要求对支持异步协作、无缝集成DevOps工作流程和尽可能自动化整个DevOps生命周期的工具提出了要求。DevOps工具的类别包括：
- 项目管理工具—使团队能够建立积压的用户故事（需求），形成编码项目，将其分解成更小的任务，并跟踪任务的完成情况。许多工具支持敏捷项目管理实践，如Scrum、Lean和Kanban，这些都是开发人员带到DevOps的。流行的开源选项包括GitHub Issues和Jira。
- 协作式源代码库 – 版本控制的编码环境，允许多个开发人员在同一代码库中工作。代码库应该与CI/CD、测试和安全工具集成，这样当代码被提交到库中时，就可以自动进入下一个步骤。开源代码库包括GiHub和GitLab。
- CI/CD管道—自动检查、构建、测试和部署代码的工具。Jenkins是这个类别中最流行的开源工具；许多以前的开源替代品，如CircleCI，现在只提供商业版本。说到持续部署（CD）工具，Spinnaker跨越了应用程序和基础设施作为代码层之间。ArgoCD是另一个流行的Kubernetes原生CI/CD的开源选择。
- 测试自动化框架 – 这些包括软件工具、库和最佳实践，用于自动化单元、合同、功能、性能、可用性、渗透和安全测试。这些工具中最好的支持多种语言；有些使用人工智能（AI）来自动重新配置测试，以响应代码的变化。测试工具和框架的范围很广。流行的开源测试自动化框架包括Selenium、Appium、Katalon、Robot Framework和Serenity（以前被称为Thucydides）。
- 配置管理（基础设施即代码工具 – 这些工具使DevOps工程师能够通过执行脚本来配置和提供完整的版本和完全记录的基础设施。开源选项包括Ansible（Red Hat）、Chef、Puppet和Terraform为容器化的应用程序执行同样的功能（见下文 “DevOps和云原生开发”）。
- 监控工具—这些工具帮助DevOps团队识别和解决系统问题；它们还实时收集和分析数据，以揭示代码变化如何影响应用性能。开源监控工具包括Datadog、Nagios、Prometheus和Splunk。
- 持续的反馈工具—通过热图（记录用户在屏幕上的操作）、调查或自助式问题单来收集用户的反馈。
DevOps和云原生开发
云原生）是一种利用基础云计算技术来构建应用的方法。云原生的目标是在公共、私有和多云环境中实现一致的、最佳的应用开发、部署、管理和性能。
今天，云原生应用程序通常是
- 使用微服务构建–松散耦合、可独立部署的组件，它们有自己独立的堆栈，并通过REST APIs、事件流或消息中介相互通信。
- 部署在容器中–可执行的代码单元，包含运行应用程序所需的所有代码、运行时和操作系统依赖。(对于大多数组织来说，”容器 “是Docker容器的同义词，但也存在其他容器类型）。
- 使用Kubernetes（https://www.ibm.com/cloud/learn/kubernetes）进行操作（规模），这是一个开源的容器协调平台，用于调度和自动部署、管理和扩展容器化的应用程序。
在许多方面，云原生开发和DevOps都是为彼此而生的。
例如，开发和更新微服务–即向小型代码库迭代交付小型代码单元–是DevOps快速发布和管理周期的完美结合。而且，如果没有DevOps的部署和操作，就很难处理微服务架构的复杂性。最近IBM对开发者和IT主管的调查发现，78%的当前微服务用户期望增加他们在架构上投入的时间、金钱和精力，56%的非用户可能在未来两年内采用微服务。要探索他们列举的一些具体的微服务好处和挑战，请使用下面的互动工具。
通过打包和永久修复所有操作系统的依赖性，容器实现了快速的CI/CD和部署周期，因为所有的集成、测试和部署都发生在同一个环境中。而Kubernetes编排为容器化的应用程序执行与Ansible、Puppet和Chef为非容器化的应用程序执行相同的持续配置任务。
大多数领先的云计算供应商—包括AWS、谷歌、微软Azure和IBM云—都提供某种管理的DevOps管道解决方案。
DevOps和站点可靠性工程（SRE）
网站可靠性工程（SRE）使用软件工程技术来实现IT运营任务的自动化—例如生产系统管理、变更管理、事件响应、甚至应急响应—这些任务本来可能由系统管理员手动完成。SRE试图将经典的系统管理员转变为工程师。
SRE的最终目标与DevOps的目标相似，但更具体：SRE旨在平衡一个组织对快速应用开发的渴望与满足与客户和最终用户的服务水平协议（SLA）中规定的性能和可用性水平。
网站可靠性工程师通过确定由应用程序引起的可接受的操作风险水平—称为 “错误预算”—以及通过自动化操作来达到这一水平来实现这种平衡。
在一个跨职能的DevOps团队中，SRE可以作为开发和运营之间的桥梁，提供团队所需的指标和自动化，以尽快通过DevOps管道推送代码变化和新功能，而不 “破坏 “组织SLA的条款。