2020年开发运维工具清单：选择开发运维工具堆栈吧

全文共7442字，预计学习时长25分钟

 

图源：unsplash

 

开发运维改革终于成为主流，人们对开发运维工具的欢迎程度暴增。根据谷歌趋势的显示，“开发运维工具”的搜索量稳定增长，且会继续保持增长。

 

由于DevOps包括整个软件开发周期，可供选择的工具很多。当然啦，没有一种工具能适合所有情况。但有几种工具的性能已经成熟，可以为几乎所有情况提供广泛的支持。

 

成功且成熟地采用开发运维方法，你将始终拥有完整的渠道，这包括适用于五个类别的工具。记住，评估当前的工具堆栈很有必要，确保没有丢失CI/CD管道的关键内容。

 

 

开发和构建工具

 

 

这是CI / CD管道堆栈的基础，一切始于此。该类别中最好的工具可以协调多个事件流，并且可以轻松地与外部工具集成。软件开发生命周期中的工具分为三个子类别：

 

· 源代码控制管理 (SCM)

· 持续集成 (CI)

· 数据管理

 

2020年推荐的源代码控制管理（SCM）技术是GIT，因此SCM工具必须具有出色的GIT支持；对于持续集成（CI），需要具备在临时容器化环境中运行和执行构建的能力；而对于数据管理，需要能够对数据库架构进行更改并使它与应用程序版本保持一致的能力。

 

1. SCM + CI工具：Gitlab和Gitlab-CI

 

图源：unsplash

 

Gitlab无疑是最伟大的开发运维周期工具，且它将在可预见的未来成为创新引领者。其核心功能提供了完美的GIT存储库管理工具，它基于网络的用户界面且易于使用。Gitlab可免费提供所需的一切，并且具有SaaS和On-Prem两种形式。

 

市场上有很多SCM工具，但是没有一种工具像Gitlab那样将“持续集成”直接集成到存储库中的。将一个名为.gitlab-ci.yml的文件粘贴在代码库的根目录中，任何GIT事件都会根据定义的内容触发操作。

 

其优点包括：

 

· 成熟：该产品自2013年以来已投放市场，非常稳定，得到大力支持。

 

· 开源：Gitlab的免费版本没有削减开发团队所需的核心功能。每个付费层都提供了附加功能，这些附加功能基于组织的规模和需求可以带来极高的价值。

 

· 根深蒂固的CI：市场上其他工具不能将持续集成直接嵌入到SCM中，而Gitlab-CI工具可以。使用Docker构建进行临时构建的能力提供了无忧的构建作业，并且内置的报告使调试构建失败变得容易，无需复杂的集成和编排多个工具。

 

· 无限集成 ：Gitlab提供了每个核心开发运维类别中所需的轻松集成工具，这使开发人员和操作人员在任何环境中都可以使用真实的来源来获取与其应用程序相关的信息。

 

其他工具在该领域也很流行，但是它们不如Gitlab。原因如下：

 

· GitHub ：对于小型和早期开发商，GitHub只是一个出色的SaaS源代码管理系统。但对于需要在网络中保留其IP的大型企业，GitHub的唯一选择是 .OVA虚拟机，不支持高可用性，从而难以维护on-prem，只能在服务器本身开始崩溃之前运行于中型组织机构。

 

GitHub Actions或CI-as-Code的缺乏意味着始终需要带上自己的CI工具，并管理该集成，而且它比Gitlab定价要贵一些。

 

· Jenkins：尽管Jenkins已成为持续集成工具的默认标准，但它始终缺少源代码控制元素。这意味着你得一直使用Jenkins和SCM工具，而GitLab同时提供这两种功能，这简直是不必要的复杂。

 

· BitBucket/Bamboo：它需要两种工具才能完成Gitlab的一项工作，尽管BitBucket云端支持Gitlab-CI/GitHub Action功能，但没有一家公司会轻易采用它，用于本地的BitBucket服务器甚至不支持BitBucket管道！

 

2.数据管理工具:FlywayDB

 

 

网络应用程序开发中最容易忽视数据库的自动化需求，通常是对应用程序的新版本部署数据库架构更改的事后思考，其模式更改通常会添加或重命名列或表。如果应用程序版本与架构版本不匹配，该应用程序可能会完全损坏。

 

由于存在两个不同的系统，因此通过应用程序升级来协调数据库更改也比较困难，而FlyWayDB解决了所有这些问题。

 

其主要优势在于：

 

· 数据库版本控制：FlyWay允许简单地创建数据库版本，跟踪数据库迁移以及轻松地前滚或回滚架构更改，无需某些定制解决方案。

 

· 二进制或内置：可以选择在应用程序启动时或二进制执行文件时运行Flyway。在代码中使用此工具，它能在启动时检查版本功能并进行适当的迁移，从而使数据库和应用程序版本保持同步。还可以临时运行命令行，为现有数据库提供灵活性，无需重建整个应用程序。

 

该领域没有很多工具只有两个竞争对手可以看看:

 

· LiquiBase ：如果对该工具有更多经验的人，那么我非常乐意通过FlyWay将该工具标准化。

 

· Flocker ：这可能仅适用于容器化的应用程序——在容器中运行数据库非常困难，必须精心计划才能成功执行。建议将RDS之类的服务用于数据库，而不要尝试运行存储在容器中的关键数据。

 

 

自动化测试工具

 

 

首先将自动化工具安装到测试金字塔中，进而开始对自动测试工具进行评估，测试有四个方面：

 

· 单元：这是所有自动化测试的基础。就数量而言，与其他类型相比，单元测试应该是最多的。这些测试应由软件开发人员编写和运行，以确保应用程序的一部分（称为“单元”）符合其设计并按预期运行。

 

· 组件：组件测试的主要目的是验证测试对象的输入/输出行为。这可以确保测试对象的功能按照所需的规范正常工作。

 

· 集成 ：在测试阶段，各个软件模块组合在一起并作为一个整体进行测试。

 

· 端到端 ：此层是一目了然的。研究从头到尾的整个应用程序流程，使其表现出预期的效果。

 

1.集成测试工具: Cucumber

 

 

Cucumber将规范和测试文档合并为一个紧密结合的有效文档。由于它们是由Cucumber自动测试的，因此规格总是最新的。

 

如果要开始构建网络自动化测试框架，并模拟网络应用程序上的用户行为，具有Java和Cucumber BDD的Selenium WebDriver是在项目中学习和实现Cucumber的好方法。

 

其主要优势在于：

 

· 基于行为驱动的开发：Cucumber用于BDD测试，它已成为一种测试框架（与传统基于测试驱动的开发相比）。

 

· 有效的文档 ：记录所做的事情总是很痛苦的。由于你的测试被定义为代码，因此Cucumber测试会自动生成文档进行匹配以确保它们始终保持同步。

 

· 支持：有很多工具可供选择，但总需要维修者来帮帮忙。Cucumber拥有足够的资金和支撑结构在未来几年维护该工具。

 

该领域有许多框架和特定技术的工具，但是只有Cucumber几乎是万能的解决方案。

 

 

端对端测试工具

 

进行端到端测试时，有两个重点领域需要关注：功能测试和负载测试。

 

图源：unsplash

 

功能测试显然是在测试幻想发生且实际发生的事情。当单击SPA上的某些页面，填写表格并单击提交时，数据显示在数据库中，并且屏幕会显示成功的字样。

 

还需要能够测试在相同场景下工作的x数量的用户是否可以正确处理。如果在这两个方面都没有进行测试，CI / CD管道中的差距将很大。

 

1.端到端测试工具—功能：SoapUIPro

 

 

自默认SOAP网络服务开始，SoapUI进入API测试领域已有很长时间了。虽然不再构建新的SOAP服务，也没有更改该工具的名称，但这并不意味着它没有发展。

 

SoapUI为构建后端网络服务的自动化功能测试提供了一种出色的结构。这些可以轻松地与持续集成工具结合，并作为CI/CD管道的一部分运行。

 

其主要优势在于：

 

· 广泛的文档：此工具已经存在了一段时间，因此有许多线上资源可帮助确定如何配置负载测试。

· 易于使用：虽然有几种适用的API测试工具，但一个接口用于多种服务，会使测试构建变得简单。

 

其竞争对手有Selenium：Selenium是该领域的出色工具，建议在构建和运行基于Java的应用程序时使用。但如果正在使用多种技术来处理一个完整的网络应用程序，使用非Java语言可能会有些笨拙。

 

2.端到端测试工具—负载测试：LoadRunner

 

 

只有LoadRunner才能完成对应用程序各个方面的负载测试。虽然价格昂贵而且入门有些困难，但它是唯一可以执行测试的工具。作为一名技术架构师，笔者相信新代码将在极端压力下执行。

 

其主要优势在于：

 

· 广泛的文档：该工具也已经存在了一段时间，有丰富的在线资源。

· 协议支持：从ODBC到AJAX，再到HTTPS以及可能在某处使用的其他隐晦协议，负载测试都支持该协议。要避免串接多个负载测试工具，这只会增加复杂性。

 

同样，该领域并没有很多万能的工具，简单的解决方案是可以在任何环境中使用。

 

 

部署工具

 

 

部署工具可能是应用程序开发中鲜为人知的方面。对于操作人员来说，如果不深入了解应用程序代码和功能，就很难使用部署工具。而对于开发人员来说，管理代码部署是一项新的职责，他们很少有使用许多部署工具的经验。

 

1.构件管理工具: Nexus

 

 

Nexus工件存储库支持从Java到NPM再到Docker几乎所有主要的技术，可以使用这一工具来存储所有可部署的工件。

 

通过使软件包更接近构建过程，代理远程软件包管理器的能力大大提高了CI配置的速度。这样做的另一个好处是可以全局查看跨多个软件项目用途的软件包，从而锁定不安全的开源软件包，这可能是代码中的攻击媒介。

 

其主要优势在于：

 

· 技术支持：该产品自2013年投放于市场上，一直都非常稳定，获得了良好支持。

· 开源：免费版的Gitlab并没有削减开发团队所需的核心功能。每个付费层均提供附加功能，这些附加功能可带来最大价值，具体取决于组织的规模和需求。

 

2.配置管理工具: Ansible

 

 

Ansible是这个领域的引领者，原因很简单：无状态。早期的现场配置管理工具着重于管理配置状态。如果它与所需的配置脱离同步，将自行修复。新的应用程序只有无状态组件。

 

其主要优势在于：

 

· 无状态：Ansible playbooks运行于操作机器上。笔者不在乎远程对象的状态，使用Packer之类的工具来构建可部署对象变得更加容易。

 

· 开源：与CentOS一样，RedHat也维护Ansible。该企业及其高级支持人员可以帮助维护社区，并确保高质量、易于使用的模块。

 

· 分子测试：由于配置管理与其他任何代码一样，如果不对其进行测试将无法开始操作。用于测试Ansible角色的分子框架可以无缝地工作，以确保代码配置的高质量，并遵循与应用程序代码相同的CI/CD管道。

 

· YAML：与其他工具相比，YAML更容易让人头脑清醒。通常来说，配置管理对于采用开发运维的任何人都是新事物。

 

图源：unsplash

 

其竞争对手有以下两个：

 

· OpsCode Chef：笔者是以chef cookbook开发人员的身份开始开发运维生涯的。Ruby和Chef十分相近，但是它们根本无法解决目前无状态、云原生应用程序的问题。对于更传统的应用程序来说，这是一个不错的工具，但本文着眼于未来。

 

· Puppet：Puppet从未发展过庞大的社区，尤其与Chef 和Ansible相比而言。它非常适合配置和裸机，但不支持网络应用程序类型的配置管理。

 

3.部署工具: Terraform

 

 

Terraform解决了从网络组件到实际服务器图像的基础架构，即代码定义问题。自最初发布以来，它已经发展了一段时间，并建立了庞大的插件社区和支持社区，为可能遇到的几乎所有部署情况提供帮助。支持本地环境、云环境或其他任何类型环境的能力是首屈一指的。

 

最后，与任何其他传统的编程语言一样，最新版本在HCL中提供了相同的逻辑功能和类，开发人员可以轻松获得和学习。

 

其主要优势在于：

 

· 不可知的云/环境：Terraform利用其代码与所有API和后端逻辑之间的接口，这些API和后端逻辑是基础架构提供商进行通信所需的。

 

· 开源：免费工具也很难做到，其社区支持是一流的。

 

其竞争对手有AWS Cloud Formation：即使仅在AWS云环境中工作，你也可能会向未知的方向继续前进，将技能和知识整合到一个平台中可能会有风险。另外，许多新AWS服务通常在用于CloudFormation之前作为Terraform模块提供。

 

 

开发运维工具运行

 

 

任何开发项目的最终目标都是在生产中运行应用程序。在开发运维领域中，要确保我们对该环境中的任何潜在问题具有可见性，并且将人工干预降至最低。选择正确的运行时工具集对于实现发展至关重要。

 

1.工具即服务: AWS

 

 

亚马逊一直是云计算领域的引领者。它们也不仅止步于此，还提供了许多新服务供开发人员利用，让人眼花缭乱。将任何技术和任何模式带到AWS上，它就可以被构建和运行。

 

与在自己的数据中心中构建、管理和维护传统硬件相比，它们的成本极其合理。免费服务使任何人都有机会先进行尝试，再做出购买决定，这对尝试以正确的方式构建应用程序非常有用，而不是因为成本而不得不妥协。

 

其主要优势在于：

 

· 行业标准：如果有在AWS中构建应用程序的经验，那么基本上可以在任何地方找到工作。企业喜欢AWS，而创业公司喜欢AWS的低成本。

 

· 免费服务：与其他所有内容相比，这是AWS拥有的极其正确的业务。先使用该服务并知道其工作原理，然后再决定将数千美元投入可能的巨大陷阱中。

 

其竞争对手有以下几个：

 

· Azure：自发布以来，Azure已经有所发展。但是，区分自身的需求导致其对服务进行了奇怪的命名，而这些服务让人难以了解——到底什么是“ 云端的文件系统”。尽管.NET代码在微软生态系统中效果更好，但在应用程序的各个方面只使用.NET是不可能的。

 

· Heroku：除了在Heroku上运行个人项目之外，笔者不会运行任何其他项目。它的透明度不高，企业没有理由将其用作平台。这对演示博客中的内容非常有用，但是对实际应用程序不太友好。

 

2.编制工具:OpenShift

 

 

你可能在应用程序堆栈中的某处使用了Docker或Container。无服务器的应用程序虽然不错，但不能适应所有架构模式。在没有业务流程平台的情况下运行容器根本行不通。

 

从安全性和工具角度来看，Core Kubernetes带来了很多需求。OpenShift是唯一的Kubernetes平台，它具有Source2Image构建，pod中的部署自动化，甚至有可追溯性和监视功能。它可以在本地，云中或同时在两者中运行。

 

其主要优势在于：

 

· 内置安全性：管理K8安全性几乎需要博士学位。默认情况下，OpenShift所采用的安全机制减少了开发人员的工作量，并为他们的应用程序提供了更安全的平台。

 

· 多合一解决方案：与默认不包含负载平衡工具的基础型K8不同，OpenShift拥有所有功能。可以用它来托管Container，构建Container，运行CI/CD工具，编排外部流程，管理机密等等。尽管GUI仍然需要做更多的工作，但API优先的方法意味着一切都可以进行编写，并且与K8的其他GUI不同，它使学习Kubernetes基础知识变得更加简单，无需以获得该学位为首要任务！

 

其主要竞争对手是Docker Swarm：Dockerswarm试图删除很多东西来简化K8。这对于较小的应用程序非常有用，但对于企业应用程序根本不起作用。此外，AWS ECS之类的服务采用了类似的方法，却使正在交互的其他服务（Lambda、IAM等）使用起来更简单。

 

3.监控工具: NewRelic

 

 

New Relic的早期发行成功地实现了APM监控。现在，它是一套完整的监控工具，可以监控服务器性能，容器性能，数据库性能，以及进行最终用户体验监控，当然还有APM监控。

 

其主要优势在于：

 

· 易于使用：在担任系统工程师的时候，我曾使用过许多监控工具，但都不如NewRelic这样易于使用。这是一种软件服务（SaaS），无需设置服务器组件，十分便捷。

 

· 端到端可见性：其他工具试图监控应用程序的某个特定方面。无论是CPU利用率还是网络流量，这些都可以协同工作，使应用程序正常运行。NewRelic使你能够整合所有数据，真实了解正在发生的事情。

 

其竞争对手有以下几个：

 

· Zabbix：Zabbix是笔者第一个最喜欢的监控系统，但是它不能发展到原生云版本，而且APM空间使它发展滞后了。不过，它仍然可以很好地监控传统的服务器基础结构。

 

· DataDog：该工具过多地侧重于管理生产应用程序的过程，而忽略代码本身。在有开发人员参与生产的开发运维团队中，无需依靠繁琐的工具来提供顶级的支持。

 

4.记录工具: Splunk

 

 

他们长期以来一直是日志聚合的领跑者，并且会继续努力做到最好。借助本地和SaaS产品，可以在任何地方使用它。它的主要缺点是运行的成本很高。

 

其主要优势在于：

 

· 行业标准：企业喜欢使用Splunk，他们也有资金来支付。虽然初创企业可能难以承担其成本，但许多概念和技能可以转移到开源替代方案中。

 

· 可支持性：它具有许多默认设置和即用型功能，因此不必花费大量时间阅读文档并尝试使用一些没有明确说明的内容。

 

其主要竞争对手是ELKStack：ElasticSearch、LogStash和Kibana似乎很受欢迎，因为它们不收取使用费用，但随着日志集的增多以及工具中越来越多的应用程序，确实会变得更加难以维护。与使用Splunk相比，在构建任何类型的仪表板之前，你会花更多的时间来设置工具。

 

 

协作开发运维工具

 

开发运维首先是组织内部的文化变革。虽然购买工具不会一夜之间改变文化，但无疑可以帮助培养与同事合作的新方式。

 

1.问题跟踪工具: Jira

 

 

尽管该领域的竞争日益激烈，但Jira仍然保持领先地位。但Jira内置的强大灵活性使开发团队和运营团队可以管理其项目工作和冲刺任务，使用敏捷术语的内置标准有助于缓解从传统工作方法到更加精益的流程的文化转变。

 

其主要优势在于：

 

· 行业标准：与许多工具一样，Jira基本在各地都有使用。小型团队可以使用便宜的许可证并获得所需的一切，而企业能为任何人承担许可证。

 

· 集成：在该领域处于领先地位并且快速增长意味着第三方工具会选择首先构建本机集成，而它们只会增加工具的价值，Jira就是这种情况。可以与现有列表中的所有其他工具集成，几乎不需要进行定制。

 

其竞争对手有以下几个：

 

· Trello：Trello成为免费使用的Kanban工具而迅速流行。但当从数十个问题扩展到数千个问题，Trello会变得难以控制、搜索和进行报告。

 

· Pivotal Tracker：在为初创公司工作时，笔者非常喜欢这个工具。但他们更多地关注产品管理，而不是技术任务。尽管通过Jira进行产品管理比较困难，但是仍然可以完成此过程，无需获取完全独立的工具。

 

2.聊天运营工具:MatterMost

 

图源：unsplash

 

这可能是2020年清单上最大的惊喜。MatterMost使用了以前最好的工具，引入了本地部署，获得了广泛的欢迎。对于企业来说是巨大的好处，因为它可以控制数据，还有助于与本地工具集成。

 

其主要优势在于：

 

· 开源：MatterMost的开源版本非常适合小型或大型团队。不同的是，在Slack的免费服务中如果丢失历史记录，运行服务器意味着找回数据。

 

· 集成：由于该API几乎100％基于Slack API，所以几乎所有Slacks集成都可以直接与MatterMost一起使用。

 

其竞争对手主要有以下两个：

 

· Slack：Slack真的很不错，但它们已经发展迅猛，需要开始盈利。他们业务的付费阶段即将到来，Slack曾经免费提供的许多功能开始需要付费，包括聊天记录。

 

· 微软团队：尝试将微软产品与非微软本地产品集成的话，祝你好运。

 

3.文档工具:Confluence

 

图源：unsplash

 

无论使用哪种工具，都很难创建和维护高质量的技术文档。尽管最近有许多SaaS文档工具进入市场，但将关键应用程序的敏感技术文档存储给第三方这一点让人难以接受。需要将数据和文档保留在本地，这就是Confluence的作用。

 

其主要优势在于：

 

· 易于管理：启动大多数自托管工具可能会有些复杂，而且大规模地对其运行和维护需要一些特定的知识。开箱即用的Confluence服务器可以适用于10个或10000个用户。

 

· 插件：尽管创建具有默认融合功能的、美观且易于浏览的文档已经很不错了，但是拥有用于几乎所有内容的插件功能激发了Wiki的潜力。

 

其竞争对手有以下几个：

 

· Read the docs：非常适合开源公共代码，但是从不考虑存储关键的应用程序知识。

 

· MarkDown：虽然非常适合于记录有关代码的事情，但很难将体系结构，过程或其他类型的文档直接放入MarkDown格式中。

 

· Jekyll：在记录技术知识时，希望构建一个新的静态站点，以便在每次更改时进行部署。简单的Confluence版本管理系统使内部文档更加易于处理。

 

市场上有数百种开发运维工具，浏览筛选应该使用的工具以及它们的执行时间是大势所趋。遵循本指南，为完整的CI/CD管道选择开发运维工具堆栈吧。

 

关键是要记住，将一切事物自动化！

 

一起分享AI学习与发展的干货
欢迎关注全平台AI垂类自媒体 “读芯术”

（添加小编微信：dxsxbb，加入读者圈，一起讨论最新鲜的人工智能科技哦～）