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