立即开始使用最好的 DevOps 工具！
DevOps 革命终于席卷了世界，DevOps 工具变得异常流行。 根据服务 ，对“DevOps 工具”的请求数量不断增长，并且这种趋势仍在持续。
DevOps 方法涵盖整个软件开发生命周期，因此专业人员可以从各种工具中进行选择。 但是，如您所知，没有任何工具可以成为每个人的通用工具。 然而，一些解决方案提供了如此广泛的功能，几乎可以处理任何任务。
让我们将 DevOps 工具分为几类，并将它们与类似工具进行比较：
- 开发和构建工具
- 测试自动化工具
- 组织部署的工具
- 运行时工具
- 协作工具。
成功且周到的实施 包括上面列出的所有五个组的乐器。 分析项目中当前的工具集，以免错过 CI/CD 管道的重要元素。
开发和构建工具
这是 CI/CD 管道堆栈的基础。 一切就从这里开始！ 此类别中最好的工具可以管理多个事件流并轻松与其他产品集成。
在开发生命周期的这个阶段，存在三组工具：
- 版本控制系统（SCM）
- 持续集成（CI）
- 数据管理
GIT 在 2020 年取得了良好的记录，因此您的 SCM 工具应该对 GIT 具有无缝支持。 对于 CI，先决条件是能够在隔离的容器环境中执行和运行构建。 在数据管理方面，需要能够根据应用程序版本更改数据库模式并维护数据库。
SCM + CI 工具 #1
赢家： 亚搏体育appGitLab和GitLab-CI
2020 年 DevOps 周期的最佳工具毫无疑问是 GitLab，并且它肯定会在不久的将来继续引领创新。
GitLab 的主要功能是提供对 Git 存储库的舒适管理。 网络界面直观且易于使用。 GitLab 以免费版本提供您所需的一切，并以 SaaS 和本地部署（使用您自己的资源来托管软件）的形式提供。
没有其他 SCM 工具直接在您的存储库上使用持续集成 (CI)，GitLab 长期以来一直这样做。 要使用 GitLab-CI，您必须将 .gitlab-ci.yml 文件添加到源代码根目录，对项目的任何更改都将根据您指定的内容触发操作。 GitLab 和 GitLab-CI 当之无愧地被公认为持续集成（CI-as-code）领域的领导者。
主要好处
- 可靠性——产品自2013年上市以来； 稳定的; 很好的支持。
- 开源 - GitLab 的免费版本不限制开发团队需要的核心功能。 付费服务包为不同规模和需求的公司提供了额外的有用功能。
- 根深蒂固的 CI - 市场上没有其他工具像 GitLab-CI 一样直接构建到 SCM 中的持续集成。 使用 Docker 可确保无障碍的独立构建，并且内置报告使调试变得轻松。 我们不需要同时对多个工具进行复杂的集成和管理。
- 无限集成 - GitLab 提供您所需的所有 DevOps 工具的轻松集成。 这确保了开发和维护团队在任何环境中都拥有有关其应用程序的单一信息源。
竞争对手
参加过战斗，但没有获胜
此类别中还有其他流行的工具，但它们不如 GitLab。 这就是为什么：
GitHub上 — 这是一个优秀的 SaaS 版本控制系统，适合小公司和早期开发阶段。 对于将 IP 地址保留在自己的网络上非常重要的大公司来说，GitHub 的唯一解决方案是不支持高可用性系统的 .OVA 虚拟机。 这使得本地维护变得困难；此外，.OVA只适合中型企业，否则服务器在更大的负载下很容易崩溃。 缺少 GitHub Actions（直到最近还没有本地版本）或 CI 即代码意味着您需要选择单独的 CI 工具，然后管理该集成。 最后，GitHub 比 GitLab 的任何一个版本都贵得多。
詹金斯 ——虽然Jenkins默认被认为是持续集成工具中的标准，但它一直缺乏版本控制能力。 原来你使用的是Jenkins加上某种SCM工具。 当 GitLab 能够同时做到这两点时，那就太难了。 平庸的用户体验设计不适合现代 Web 应用程序，并且还有很多不足之处。
BitBucket/竹子 — 我必须承认他是一个自动失败者：当 GitLab 完全独立完成所有事情时，为什么还要使用两个工具。 BitBucket Cloud 支持 GitLab-CI / GitHub Action 功能，但没有一家比初创公司更大的公司可以轻松实现它。 本地 BitBucket 服务器甚至不支持 BitBucket 管道！
#1 数据管理工具
赢家： Flyway数据库
在 Web 应用程序开发中，数据库自动化通常不被重视。 为新版本的应用程序部署数据库架构更改的想法来得很晚。 架构更改通常会导致添加和重命名列或表。 如果应用程序版本与架构版本不匹配，应用程序可能会崩溃。 此外，由于存在两个不同的系统，因此在更新应用程序时管理数据库更改可能具有挑战性。 FlyWayDB解决了所有这些问题。
主要好处
- 数据库版本控制 - Flyway 允许您创建数据库版本、跟踪数据库迁移以及轻松传输或恢复架构更改，而无需额外的工具。
- 二进制或嵌入式 - 我们可以选择将 Flyway 作为应用程序的一部分或作为二进制可执行文件运行。 Flyway 在启动时检查版本兼容性并启动适当的迁移，保持数据库和应用程序版本同步。 通过运行命令行临时命令，我们为现有数据库提供了灵活性，而无需重建整个应用程序。
竞争对手
参加过战斗，但没有获胜
该领域的工具并不多。 让我们看看其中的一些：
液体基地 — Liquibase 类似于 FlywayDB。 如果我的团队中有人在 Liquibase 方面拥有更多经验，我希望将其设置在 Flyway 之上。
植绒 - 只能适用于容器化应用程序。 要成功运行容器化数据库，一切都必须完美规划。 我建议使用 RDS（关系数据库服务）作为数据库，并且不建议将重要信息存储在容器中。
测试自动化工具
让我们根据测试金字塔对测试自动化工具进行分类来开始讨论。
测试金字塔（测试）有 4 个级别：
- 单元测试——这是整个自动化测试过程的基础。 与其他类型的测试相比，应该有更多的单元测试。 开发人员编写并运行单元测试，以确保应用程序的一部分（称为“单元”）符合其设计并按预期运行。
- 组件测试- 组件测试的主要目的是验证测试对象的输入/输出行为。 我们必须确保测试对象的功能按照规范正确实现。
- 集成测试 - 一种将各个软件模块组合起来并作为一个组进行测试的测试。
- 端到端测试 - 此步骤是不言自明的。 我们监控整个应用程序并确保其按计划运行。
由于单元测试和组件测试仅由开发人员执行，并且通常是特定于编程语言的，因此我们不会针对 DevOps 领域评估这些工具。
#1 集成测试工具
赢家： 黄瓜
Cucumber 将规范和测试文档合并到一个活动文档中。 这些规范始终是最新的，因为它们是由 Cucumber 自动测试的。 如果您想从头开始构建自动化测试框架并在 Web 应用程序中对用户行为进行建模，那么带有 Java 和 Cucumber BDD 的 Selenium WebDriver 是在项目中学习和实现 Cucumber 的好方法。
主要好处
- BDD 方法（行为驱动开发 - “通过行为进行开发”，而不是“测试驱动开发”方法）- Cucumber 是为 BDD 测试而设计的，它最初就是为此任务而创建的。
- 动态文档 - 文档总是很痛苦！ 由于您的测试是作为代码编写的，Cucumber 会测试自动生成的文档，以确保测试和文档同步。
- 支持 - 我们可以从许多工具中进行选择，但 Cucumber 拥有必要的财务资源和组织良好的支持系统，可以在任何困难情况下帮助用户。
竞争对手
参加过战斗，但没有获胜
在其他框架和技术专用工具中，只有 Cucumber 可以被认为是通用解决方案。
端到端测试工具
在进行端到端测试时，需要关注两个关键点：
- 功能测试
- 压力测试。
在功能测试中，我们检查我们想要的一切是否真的发生了。 例如，当我单击 SPA（单页应用程序）的某些元素、填写表格并选择“提交”时，数据会出现在数据库中，并且屏幕上会出现消息“成功！”。
对于我们来说，检查是否可以正确处理运行相同场景的一定数量的用户也很重要。
缺乏这两种类型的测试将是 CI/CD 管道中的一个重大缺陷。
#1 端到端测试工具。 功能测试
赢家： SoapUI专业版
自从基于 SOAP 的 Web 服务成为标准以来，SoapUI 已经进入 API 测试领域很长时间了。 虽然我们不再创建新的 SOAP 服务并且该工具的名称也没有更改，但这并不意味着它没有发展。 SoapUI 提供了一个用于创建自动化后端功能测试的优秀框架。 测试可以轻松地与持续集成工具结合，并用作 CI/CD 管道的一部分。
主要好处
- 详细文档 - SoapUI 已经上市很长时间了，因此有许多在线资源可以帮助您了解如何设置测试。
- 易于使用 - 尽管该工具支持用于测试 API 的多种协议，但 SoapUI 为多种服务提供的通用接口使编写测试变得更加容易。
竞争对手
参加过战斗，但没有获胜
硒 是该组中的另一个出色的乐器。 如果您正在构建和运行基于 Java 的应用程序，我建议您使用它。 但是，如果您正在使用多种技术构建完整的 Web 应用程序，那么对于非 Java 组件来说它可能会变得难以使用。
#1 端到端测试工具。 压力测试
赢家： 加载程序
说明： 当需要对应用程序的每个元素进行负载测试时，只有 LoadRunner 可以完成任务。 是的，一开始它既昂贵又困难，但 LoadRunner 是唯一能让我作为技术架构师完全相信新代码可以在极端负载条件下工作的工具。 另外，我认为现在是时候让 LoadRunner 由开发团队而不是测试团队接管了。
主要好处
- 丰富的文档 - LoadRunner 已经上市相当长一段时间了，因此有许多在线资源可以帮助您了解如何设置负载测试。
- 协议支持 - Load Runner 支持从 ODBC 到 AJAX、HTTPS 以及您的应用程序可能使用的任何其他重要协议的所有内容。 我们尽量不使用多种工具进行负载测试，因为这只会让过程变得复杂。
竞争对手
参加过战斗，但没有获胜
同样，该领域没有很多通用工具，因此最好的解决方案是可以在任何环境中使用任何技术的解决方案。
部署工具
部署工具可能是开发中最不被理解的方面。 对于没有深入了解应用程序的代码和功能的运营团队来说，很难使用此类工具。 对于开发人员来说，部署管理是一项新职责，因此他们还没有足够的使用此类工具的经验。
首先，我们将所有部署工具分为三个子类别：
- 工件管理
- 配置管理
- 部署。
#1 工件管理工具
赢家： 关系
Nexus 工件存储库支持几乎所有主要技术，从 Java 到 NPM 到 Docker。 我们可以使用这个工具来存储我们使用的所有工件。 代理远程包管理器还可以显着加快 CI 构建过程，使包更易于构建。 另一个优点是能够获得多个软件项目中使用的所有软件包的完整视图，阻止不安全的开源软件包（它们可以充当攻击媒介）。
主要好处
- 技术支持——可靠的产品； 很好的支持。
- 开源 - 免费版本不限制开发团队所需的核心功能。
#1 配置管理工具
赢家： Ansible
Ansible 成为领导者的原因很简单：无状态。 以前，类似的工具专注于配置状态管理。 当启动时，此类工具在收到所需的配置后，将尝试更正当前的应用程序配置。 而采用新方法时，只存在无状态组件。 新版本的代码是部署来替换现有代码的工件。 这可以被认为是一种短暂的、短期的环境。
主要好处
- 无状态 - Playbook 从部署计算机启动并在目标服务器上执行。 通过使用像 Packer 这样的工具来创建可部署对象，我不必担心远程对象的状态。
- 开源 - 与 CentOS 一样，Ansible 也受 RedHat 支持。 它有助于维护社区并提供高质量、易于使用的模块。
- 使用 Molecule（Ansible 框架）进行测试 - 由于配置管理是代码，就像其他一切一样，测试至关重要。 Molecule 的 Ansible 角色测试框架完美运行，确保配置具有相同的质量，并遵循与应用程序代码相同的 CI/CD 管道。
- YAML - 与其他工具相比，YAML 更容易理解。 由于配置管理对于那些实施 DevOps 实践的人来说通常是一个新的挑战，因此简单性是它的王牌。
竞争对手
参加过战斗，但没有获胜
操作代码厨师 — 我作为食谱开发人员开始了我的 DevOps 职业生涯。 Ruby 和 Chef 当然是我非常喜欢的，但它们根本无法解决现代无状态、云原生应用程序的问题。 OpsCode Chef 对于更传统的应用程序来说是一个很棒的工具，但在本文中我们将重点关注未来。
木偶 — Puppet 从来没有太多粉丝，尤其是与 Chef 和 Ansible 相比。 它非常适合配置和使用硬件，但缺乏对 Web 应用程序的现代配置管理支持。
部署工具#1
赢家： Terraform
Terraform 解决了将基础设施描述为代码的问题，从网络组件到完整的服务器映像。 自最初发布以来，该产品已经取得了长足的进步，创建了如此多的插件并建立了如此强大的社区，您一定会在任何部署场景中获得帮助。 支持任何类型环境（本地、云端或其他地方）的能力是无与伦比的。 最后，最新版本在 HCL 中提供了与任何其他传统编程语言相同的逻辑函数和类，使 Terraform 易于开发人员快速轻松地掌握。
主要好处
- 与环境无关 - Terraform 使用充当 Terraform 代码、所有 API 和内部逻辑之间接口的函数来与基础设施提供商进行通信。 这意味着我只需掌握一种工具，然后就可以在任何地方工作。
- 开源 - 很难打败免费工具！ 最高级别的社区支持。
竞争对手
参加过战斗，但没有获胜
AWS CloudFormation — 即使您只在 AWS 云环境中工作，您的下一份工作也可能会使用不同的工具。 将所有时间和精力投入到一个平台上是一个短视的决定。 此外，许多新的 AWS 服务通常在 CloudFormation 中提供之前作为 Terraform 模块提供。
运行时工具
任何开发项目的最终目标都是将应用程序投入生产。 在 DevOps 世界中，我们希望充分了解环境中所有可能出现的问题，并且我们还希望最大限度地减少人工干预。 选择正确的运行时工具集对于实现应用程序开发天堂至关重要。
运行时工具的子类别：
- X 即服务 (XaaS)
- 编排
- 监控
- 记录。
X 工具即服务#1
赢家： 亚马逊网络服务
亚马逊一直是云技术领域的领导者，但它并不止于此：为开发人员提供的各种新服务令人大开眼界。 将任何技术和模板引入 AWS，它将被构建并运行。 该工具的成本相当合理：将其与在您自己的数据中心组装、管理和维护设备进行比较。 免费版本允许您在花钱之前进行试验并做出正确的决定。
主要好处
- 普遍性 - 如果您有在 AWS 中构建应用程序的经验，那么您可以在任何地方工作。 企业喜欢 AWS，初创公司也欣赏它的低成本。
- 免费版本是 AWS 区别于同类产品的一个真正重要的因素。 在我做出购买决定之前，让我尝试一下该服务，看看它是如何工作的，我不想花数千美元在不必要的东西上。 免费版本总是足以让我测试任何概念。
竞争对手
参加过战斗，但没有获胜
Azure “自首次发布以来，Azure 已经取得了长足的进步，这是值得赞扬的。 然而，与众不同的愿望导致了服务的奇怪名称，这往往使工作变得复杂。 “blob 存储”是什么意思？ 虽然 .NET 代码在 Microsoft 生态系统中表现更好，但您不太可能只对应用程序的每个组件使用 .NET。
Heroku的 — 由于可靠性和透明度较低，我绝不会在 Heroku 上运行个人项目以外的任何项目，因此公司不应将其用作平台。 Heroku 非常适合在博客上演示某些内容，但对于实际使用来说 - “不，谢谢！”
#1 编排工具
赢家： 开班
您可能在应用程序堆栈中使用 Docker 或其他容器。 无服务器应用程序很棒，但它们可能不适合所有架构。 在没有编排平台的情况下运行容器根本行不通。 Kubernetes Core (K8s) 在安全性和工具方面无与伦比。 OpenShift 是唯一一个基于 Kubernetes 的平台，可以收集 Source2Image，支持自动部署到 pod，并支持跟踪和监控。 OpenShift 可以在本地、云端运行，或者同时在本地和云端运行。
主要好处
- 内置安全性 - 管理 K8s 安全性可能需要高级程度。 每个细节都必须仔细考虑并考虑在内！ OpenShift 默认内置的安全机制减轻了开发人员的负担，并为应用程序提供了更安全的平台。
- 一体化解决方案 - 与默认情况下不包含负载平衡工具的基本 K8 不同，OpenShift 拥有这一切。 我可以使用它来创建和托管容器、运行 CI/CD 工具、管理外部进程、管理密钥等等。 尽管图形用户界面还远未达到完美，但基于 API 的方法意味着一切都可以在脚本中描述。 与其他 K8s GUI 不同，OpenShift 使学习 Kubernetes 的基础知识变得更加容易。 您甚至不需要获得学位！
竞争对手
参加过战斗，但没有获胜
码头工人 — Docker Swarm 试图通过摆脱许多东西来简化 K8s。 它对于小型应用程序来说非常有用，但对于企业应用程序来说它不起作用。 此外，AWS ECS 等解决方案采用类似的方法，但可以更轻松地与我可以交互的其他服务（Lambda、IAM 等）配合使用。
监控工具#1
赢家： 新遗物
New Relic 的早期版本做得很好——APM（应用程序性能监控）监控。 它现在是一个功能齐全的监控工具，允许您监控服务器、容器、数据库性能、最终用户体验监控，当然还有应用程序性能监控。
主要好处
- 易于使用——当我作为一名系统工程师时，我使用过很多监控工具，但我从未遇到过像 New Relic 这样简单易用的工具。 它是 SaaS，因此您无需自己安装。
- 端到端可见性 - 其他工具尝试监视应用程序的一个特定元素。 例如，处理器使用率或网络流量的指标，但所有这些都必须得到全面监控，应用程序才能正常工作。 New Relic 使您能够将所有数据整合在一起，以全面了解正在发生的情况。
竞争对手
参加过战斗，但没有获胜
ZABBIX — 我的第一个也是最喜欢的监控系统，但由于云技术和APM应用程序性能监控领域缺乏发展，它一直停留在过去。 Zabbix 仍然可以很好地进行传统的服务器基础设施监控，但仅此而已。
DataDog — 过多关注管理应用程序生产环境的过程，而不是代码本身。 有了涉及开发人员的 DevOps 团队，我们不必依赖难以使用的工具来提供一流的支持。
记录工具#1
赢家： Splunk的
很难与 Splunk 竞争！ 长期以来，他仍然是伐木领域的领导者，并且继续比其他人做得更好。 借助本地部署和 SaaS 产品，您可以在任何地方使用 Splunk。 最大的缺点是它的价格：Splunk 仍然非常昂贵！
主要好处
- 普及性 - 企业喜欢 Splunk，而且公司有钱购买它。
- 尽管初创公司正在努力收回成本，但由于开源类似物，许多功能都可以得到解决。
- 可维护性——简单地说，Splunk 有效并且做得很好。 它带有许多可供使用的默认设置和功能。 无需浪费时间阅读文档并尝试让 Splunk 工作或破译任何内容。
竞争对手
参加过战斗，但没有获胜
ELK 堆栈（ElasticSearch、LogStash 和 Kibana） “这些工具似乎是最受欢迎的，因为你甚至不需要卖掉你的肝脏来使用它们。” 然而，随着日志集的增长和船上应用程序数量的增加，工作变得越来越困难。 与 Splunk 相比，使用 ELK Stack，我在创建任何仪表板之前花费了比以前更多的时间来设置工具。
协作工具
DevOps 主要是为了改变组织内部的文化。 购买任何工具都不会在一夜之间改变当前的做法，但它肯定可以鼓励协作和新的交互方式。
协作工具的子类别：
- 任务跟踪
- 聊天操作
- 文档。
#1 问题跟踪工具
赢家： JIRA
尽管该领域的竞争日益激烈，但 Jira 仍然保持着领先地位。 Jira 令人难以置信的灵活性使开发和维护团队能够管理项目工作和冲刺任务。 使用敏捷术语的内置标准可以更轻松地从传统工作方式转变为更高效的流程。
主要好处
- 受欢迎程度 - 与许多其他工具一样，Jira 几乎无处不在。 小团队使用更便宜、更容易访问的版本并获得他们需要的一切，而大公司则可以负担更昂贵的许可证。
- 集成 - Jira 是该领域的先驱。 这一事实以及产品的快速发展导致其他公司选择 Jira 来创建自己的集成，从而增加了该工具的价值。 我们可以通过一些配置将 Jira 与本文列出的所有工具集成在一起。
竞争对手
参加过战斗，但没有获胜
Trello — Trello 凭借其免费的看板工具迅速流行起来。 然而，一旦流程规模扩大并且任务从数十个增加到数千个，Trello 就会变得难以导航、搜索和报告。
关键追踪器 — 当我在一家初创公司工作时，我非常喜欢这个工具。 然而，Pivotal Tracker 更专注于产品管理而不是技术任务。 尽管 Jira 中的产品管理稍微复杂一些，但仍然可以在不使用额外工具的情况下实现。
聊天操作工具 #1
赢家： MatterMost
说明： 也许我的选择给您带来最大的惊喜，这是个好消息！ MatterMost 通过借鉴以前工具的优点并将其部署在本地而受到欢迎。 这对于公司来说非常重要：MatterMost 允许您控制数据，还可以帮助您将其与本地运行的工具集成。 我们不再需要走出防火墙来检查工作聊天记录。
主要好处
- 开源 – MatterMost 的开源版本非常适合中型和大型团队。 与 Slack 的免费计划不同，Slack 的免费计划会删除您的消息历史记录，运行您自己的服务器意味着您保留所有数据。
- 集成 - 由于 API 几乎 100% 基于 Slack API，因此几乎所有 Slack 集成都可以直接与 MatterMost 一起使用。
竞争对手
参加过战斗，但没有获胜
松弛 — Slack 很酷，但这些人已经发展得如此之快，以至于他们开始寻求利润。 业务的投资回收阶段即将到来，这会带走它们的主要价值：Slack 免费提供服务； 免费版本最重要的缺点是删除聊天记录。
微软团队 — 尝试将 Microsoft 产品与非 Microsoft 拥有的产品集成...祝你好运！ 这就是我要说的关于这个工具的全部内容！
文档工具 #1
赢家： 合流
无论您使用什么工具，创建和维护高质量的技术文档都是一个复杂的过程。 尽管最近市场上出现了许多 SaaS 文档工具，但我发现很难将有关任务关键型应用程序的技术文档的存储外包给第三方。 最好在本地存储数据和文档，这就是 Confluence 解决该问题的方法。
主要好处
- 易于操作 - 大多数独立工具的设置和操作可能有点复杂，并且需要一些知识来维护。 Confluence Server 开箱即用，适合 10 或 10,000 个用户。
- 插件 - Confluence 拥有漂亮、易于使用的开箱即用导航，并且能够为几乎所有内容添加插件，从而释放了类似 Wiki 的潜力，这值得称赞。
竞争对手
参加过战斗，但没有获胜
阅读文档 — 对于开源来说很酷，但甚至不要考虑在这里存储关键知识。
降价 - 非常适合记录代码，但由于 MarkDown 的特定格式，很难发布架构、流程或其他类型的文档。
杰奇 — 在记录技术知识时，我不想创建一个每次发生更改时都会部署的新静态站点。 Confluence 简单的版本控制系统极大地简化了内部文档。
综合
市场上确实有数百种 DevOps 工具，因此很难知道该使用哪些工具以及何时实施它们。 按照这个简单的指南为完整的 CI/CD 管道选择 DevOps 工具。
请务必从所有五个类别中选择工具：
- 开发和构建工具
- 测试自动化工具
- 部署工具
- 运行时工具
- 协作工具。
主要推荐： 自动化一切！
谢谢扎克·夏皮罗！
来源： habr.com