您的持续交付过程不能忽视的两个重要组成部分

对于许多企业而言，持续交付 (CD) 流程已成为“必需品”而非“奢侈品”。价值当然很明确：CD 可以帮助 IT 团队降低风险，同时更精简、更快、更敏捷地工作。上市时间加快，内部问题最小化。

但即使您已经在运行持续交付流程，您是否使用了正确的工具来最有效地执行它？让我们来看看持续测试和诊断工具如何与 CD 一起工作，以及如何将 BlazeMeter 和 New Relic 集成到您的 CD 流程中。

如果没有持续测试，您就无法运行有效的持续交付流程。持续交付可以将发布时间从几个月缩短到几个小时。但是，如果没有正确的测试，您的 CD 过程注定会失败。随着您的软件的发展，您将需要运行越来越多的测试，但是，如果您像大多数公司一样，您将只能执行其中的一小部分。您可能会面临软件质量妥协或更长的发布时间。

那么如何避免这种情况呢？持续交付所倡导的真正敏捷流程需要完全自动化，其中包括测试。自动化测试让您的流程运行得更快、更顺畅。为了使其真正有效，这种自动化测试应该在整个系统开发生命周期 ( SDLC ) 中持续集成。这将使您能够在性能问题发生之前发现并预防它们——无论您处于生命周期的哪个阶段。

这就是为什么我们认为在整个开发生命周期中集成的连续、自动化测试是持续交付成功的关键。

简而言之，持续测试和诊断是齐头并进的。

测试会告诉您故事的一方面。它可以告诉你 什么时候 会遇到问题，你会在什么时候遇到瓶颈。但是，它不会向您显示遇到瓶颈的位置或查明导致问题的应用程序区域。

由于应用程序的复杂性不断增加，查明原因比以往任何时候都更加困难。大多数现代应用程序都不由单个服务器组成。相反，服务器有多层架构和不同角色（应用程序服务器、后端、存储和数据库服务器等）。更重要的是，其中一些服务器位于云端，而另一些则位于本地。在这种情况下，查找根本原因可能极其复杂。

要真正解决问题，您需要看到全貌。这意味着进行测试以查明您将遇到瓶颈的位置，并使用诊断工具来发现问题的根本原因。结合使用测试和诊断可为您提供解决问题所需的一切，并继续进行持续交付流程的下一步。

如前所述，高效、敏捷的流程通常需要自动化。因此，最好使用自动化工具进行测试和诊断。让我们看看 BlazeMeter 的持续测试平台和 New Relic APM 的组合，并给出一些实际示例，说明如何在软件生命周期的不同阶段使用它们。

BlazeMeter 旨在与各种持续集成、持续交付和源代码控制工具无缝集成，以在整个软件生命周期中提供连续的自动化测试。另一方面，New Relic 使您能够在生产前和生产后持续诊断您的应用程序内部结构。

例如，让我们看一下包含持续测试的典型开发工作流程。开发人员更改了代码，导致 API 调用的响应时间从 200 毫秒增加到 300 毫秒，这超过了为测试该 API 调用定义的 250 毫秒阈值。代码在他的盒子上看起来不错，因此他们执行以下操作：

现在让我们看看如何使用这些工具。

在预生产中，测试各种外部关键性能指标 (KPI) 非常重要，例如是否存在任何瓶颈和用户体验质量。同时，您还需要了解应用程序的内部行为。

假设您在预生产环境中对 BlazeMeter 运行负载测试。您可能会以不断增加的负载量运行压力测试，直到它崩溃。当您的博客上有 300 个并发用户时，您终于遇到了瓶颈（如下所示）：

BlazeMeter 已向您展示了何时会遇到瓶颈。借助 New Relic，您可以获得同一时间范围内此负载测试的一组相应图表，以帮助您发现问题发生的位置——精确到子系统和该子系统中的资源。

在后期制作中，您需要通过模拟用于测试前期制作的确切场景来监控您的应用程序或网站。了解是否出现问题或用户体验是否恶化至关重要，并且您需要再次了解应用程序的内部行为。

例如：假设您正在分析自动运行的一系列负载测试的 KPI 趋势图，您注意到趋势突然飙升。通过查看 New Relic 在同一时间段的相应图表，您可以看到它与数据库服务器子系统的峰值和硬盘驱动器资源上的 I/O 操作的巨大峰值相关——您可以理解这一点由工程师进行的数据库维护引起的（如下图）：

Loadosophia 的 KPI 跟踪图显示平均响应时间突然飙升

持续的自动化测试和诊断工具是确保软件生命周期每一步质量的关键，最终对于成功和高效的持续交付流程至关重要。

Andrey Pokhilko 是 BlazeMeter 的首席科学家。他是 Apache JMeter 和性能测试社区中著名的思想领袖和创新者。查看 Andrey Pokhilko 的帖子。

相关文章