如何在持续交付时代继续使用您最喜欢的开源工具


在“前DevOps时代”开发的工具注定要灭亡吗?通过促进随时将软件发布到生产环境,DevOps方法和Continuous Delivery流程将网站和应用程序的发布时间从几周缩短到几个小时。

不可否认,这些学科即使不是我们的现在,也是我们未来不可或缺的一部分。但它们如何与我们的过去相适应呢?

我们中的大多数人可能还在使用在“DevOps”和“持续交付”等词成为我们日常词汇的一部分之前开发的工具。这些工具,如JMeter、Siege和Gatling,都是经过考验和信任的,我们中的大多数人都不想放弃它们,但它们并不是以DevOps的心态创建的,这给我们带来了很大的问题。

您的开源工具使您的DevOps进程失败的4个方面(以及如何应对)

无论您使用的是JMeter、Siege、Gatling还是Grinder,您都可能注意到工具的功能与成功的连续交付流程的要求之间存在一些差距。新的open source source tool Taurus通过在现有开放源码工具之上创建额外级别来实现自动化,缩小了这些差距。

以下是您的工具中存在的四个最大差距implementing a successful Continuous Delivery process,还有一个关于金牛座如何帮助你克服它们的快速解释。

1.它们依赖于人类的存在

大多数工具最初是由专门的性能测试员创建的-但现在角色变得模糊了。我们通常只有一个人编写、测试和部署代码和/或高度自动化的过程-而该工具不能完全支持这一点。

例如:当JMeter执行测试失败时,它会给出退出代码0-这实际上意味着“成功”。当您在Jenkins Continuous Integration(Ci)应用程序,并且您使用JMeter执行该测试,您将无法以常规方式检测到故障,因为它总是给出退出代码0。他说,这个工具本质上是对你“撒谎”。

为什么?JMeter是在以自动和无人值守的方式运行测试之前创建的。当在用户界面(UI)中启动测试时,将弹出一条错误消息,告诉性能测试人员有问题,否则他/她将立即看到所有结果都被标记为红色。但它依赖于人类在循环中的存在。

你能对此做些什么呢?

金牛座会帮助解决这样的问题。在这种情况下,它使您能够提前设置阈值和定义失败标准,以便在KPI未达到或测试由于技术问题根本无法启动时,退出代码不会显示为“成功”。


2.它们不支持自动结果分析

假设您已经成功执行了负载测试,现在需要分析结果。

您可能想知道一些关键事实,比如结果是否符合成功标准、响应时间是否过长,以及它们是否落在预期范围内。在自动化负载测试时,如果关键性能指标(KPI)不符合服务级别协议(SLA)范围或预设阈值,则需要一种方法来检查结果并发出标志。然而,没有一个流行的开源工具在自动化该过程的这一部分方面提供了太多的帮助。大多数都专注于生成负载,而忽略了结果分析(唯一的例外是Gatling,它在运行结束时提供丰富的报告)。

有一些插件可以缓解这个问题。例如:Jenkins plugin for JMeter-帮助您设置接受范围。然而,即使这样也只有在您使用JMeter时才有效,而不是Grinder、Gatling或Locust。

你能对此做些什么呢?

Taurus为来自负载测试结果的结果提供原生格式(例如有多少测试失败),并以CI友好的样式表示它们。像Jenkins这样的高级CI应用程序能够使用测试中的数字统计数据,以便绘制随时间变化的图表和趋势。

或者,可以将这些格式输入到special reports server on BlazeMeter因此,您可以轻松查看趋势和管理结果。在这里,你实际上可以从趋势线上的一点跳到单个测试中,以便调查尖峰和不规则的来源。

3.它们没有为您提供所需级别的可伸缩性

上面提到的所有开源工具都是在大多数负载由一台机器或几台机器生成的时候创建的。多年来,互联网的普及率飙升,使用量呈爆炸式增长-但工具保持不变。

例如:Gatling没有任何内置的分布式测试功能,并且在任何人开始考虑分布式测试之前就已经创建了围城(当时AWS甚至没有提供云服务)。

但是,即使是具有分布式测试功能的工具(即JMeter和Grinder)也是为局域网(LAN)构建的,而不是针对云和地理分布的测试。JMeter的分布式测试允许您使用附近2-5台机器的资源轻松设置测试。然而,当涉及到每天使用10-15台机器启动多个测试时,您会发现您花在处理基础设施问题上的时间比实际执行测试的时间还多!

这应该不会那么难。Amazon Web Services (AWS) 这让我们的工作变得非常简单-我们应该只需要在亚马逊的不同地区调出几台机器即可。需要有一种同样简单的方法来设置性能测试。

你能对此做些什么呢?

金牛座使用其分布式测试功能来扩展以前不可扩展的功能。正如我刚才提到的,Gatling没有可伸缩性。但是,使用Taurus时,您可以将其配置为使用BlazeMeter cloud 然后你可以将其扩展到数百台机器上。

4.不支持代码的协同所有权

在过去,测试是由专门的人员进行的,他们在本地文件夹或类似的形式中维护测试配置。

今天,人们将他们的工件提交到版本控制系统中。根据敏捷实践,他们协作创建和维护测试,并且没有单一的所有者。相反,代码拥有协作所有权。虽然公司承担不起只有一个工程师的费用,但他们需要透明度,并允许其他员工在必要时接手。然而,许多开源工具不支持这一点。新用户可能很难学习该工具,很难识别随着时间的推移发生的更改,也很难理解更改了什么。

例如:在JMeter的基于XML的测试计划格式中,很难看到在VCS中通过文件编辑历史所做的差异。如果您不幸运地与其他几个人同时编辑该文件,合并冲突将是极其痛苦的!拥有一种可以像其他源代码文件一样合并的格式要好得多。

你能对此做些什么呢?

Taurus允许您用简单的术语描述负载测试:您可以只列出要命中的URL、要请求的附加头,并添加“思考时间”。您可以用一种简单的明文格式表达几个选项,并获得正确的JMeter负载测试。它会自动将您的文本配置转换为简单的XML文件。所有的复杂性都是隐藏的,这意味着您不需要了解Scala就可以在Gatling上创建负载测试,并且您根本不需要了解Scalge的配置格式。使用的文件格式是精简的和基于文本的-这使得多人修改、跟踪和合并他们的更改变得超级容易。

JMeter,加特林,围攻,研磨机和蝗虫:前DevOps,但不是史前


我们可能都在朝着持续交付的工作流程前进,但是我们中的大多数人都不想放弃我们的“经过考验的”负载测试工具。没有人有时间学习和实施一个新的工具--更不用说不得不放弃我们信任并熟悉的工具了。

理想情况下,我们希望继续使用我们最喜欢的开源工具,如JMeter或Siege,并将它们集成到我们的持续交付过程中。要实现这一点,我们只需再添加一个open source tool (Taurus)这是在DevOps和持续交付等流行语成为我们日常生活的一部分后产生的。

这篇文章最初发表在Blazemeter安德烈·波克希尔科著。