我们的大多数客户都知道CloudBees加速器。毕竟，这是该公司的第一个产品；旨在通过将makefile中的配方在任意数量的代理之间并行化，从而大大加快软件的构建速度。我们的大多数客户都看到了性能的显著提高，将构建速度提高了2倍到20倍或更多，这取决于他们的构建结构以及他们希望向群集管理器提供多少代理。大多数客户不知道的是Accelerator可以做的不仅仅是加速构建。它不仅可以使用makefile来实现它的魔力，而且实现这个功能的工具已经包含在产品中，不需要额外的许可成本。在这篇文章中，数据与大数据专业，我将讨论一些先决条件和技术，以加速与成功的持续集成和交付相关的其他活动，特别是等式中缺失的环节——持续测试。回顾：加速器的工作原理CloudBees Accelerator最著名的名声是它可以加速软件产品的构建。它通过为你的make工具（gmake、nmake、clearmake等）提供一个替代品来实现这一点，它可以自己执行任务，也可以与集群管理器对话，将构建的各个组件"分包"给"代理"。通过在多个代理之间分配工作并并行执行这些工作，它可以加快工作的完成速度，减少等待时间，并在流程中提供显著的ROI（投资回报率）。下图描述了CloudBees加速器产品最常见的配置和参考架构。当CloudBees加速器的emake处理makefile时，它使用目标和配方来理解如何并行化工作。根据每次执行时都会学习的专利算法做出这些决策，它会向集群管理器查询与构建兼容的可用代理。根据客户在集群管理器中定义的配置，大数据时代的特点，以及需要在其上完成工作的平台，然后将工作发送给代理，然后代理将结果返回集群管理器和运行emake的主机。电子文件系统负责确保代理执行工作所需的所有信息都可从主机获得，并且所有结果（包括日志和注释）都会被发回。许多其他的事情也发生在背景中，但我今天就不谈这些细节了。 代理人的概念经常被误解。代理不绑定到处理器中的核心。主机上的代理可以多于核心，也可以多于代理。配置的选择取决于在这些代理上运行的作业的I/O和CPU绑定情况。通常，我们建议从主机上的多个代理开始，这些代理与核心数匹配或略超过核心数。主机是虚拟机还是物理机无关紧要。如果主机有12个内核，如果机器将专用于加速器构建，那么可以考虑安装14个代理作为开始，但是超线程通常只产生20-30个加速。如果主机将在其他任务之间共享，则可以减少该数量。如果我想加速其他活动呢？不久之后，我们要求许多客户（如果他们自己）可以并行使用加速器。他们中的大多数人不知道答案是一个限定的"是的！"然而，有一些注意事项需要记住。如果要加速现有应用程序，可以使用以下信息，但也可以由希望为客户提供在加速器环境中使用其应用程序选项的开发人员使用。只进行单线程或多线程调用作为单个单片进程运行的应用程序或多线程的应用程序（如Java应用程序）只能作为一个进程发送给代理程序进行并行化。例如，作为单个进程运行的代码模式分析应用程序，或在Java下运行的单元测试工具，可以作为要执行的许多任务之一发送给代理，但它通常在makefile中定义并由emake处理。如果此应用程序很大并且需要很长时间才能完成，则在代理上完成运行也需要很长时间。如果只需要执行一次，那么使用Accelerator将没有任何好处，因为您只会将分发给代理、通信等的开销添加到任务中。但是，如果您有一个需要多次运行的单进程或多线程应用程序，大数据是，例如对作为解决方案一部分的多个C#项目进行模式和流分析，那么您可以从并行化中受益匪浅。以一个由七个项目组成的visualstudioc#产品为例，您需要对项目中的代码运行Parasoft的dotTEST，以便在发布产品之前尝试捕获任何潜在的问题。连续进行7次分析可能需要一些时间。假设项目位于产品主文件夹中的子文件夹中，您需要遍历文件夹结构并针对每个子文件夹运行工具。下面的示例makefile将实现该目标：PROJECTS=utils核心库外部图形gui-xml目标=$（addprefix go_x，$（PROJECTS））全部：$（目标）加油：dottestcli-nobuild-report.\project\$*-project.\project\$*\$*.csproj如果告诉emake从产品代码所在的基本文件夹处理这个makefile，它将遍历每个文件夹并在代码上运行工具，在每个文件夹中生成一个报告。要将这个任务与emake并行，可以使用类似这样的命令行。emake--emake annoupload=1--emake annodetail=basic--emake cm=——win32前两个参数将生成一个基本注释文件并将其发送到集群管理器。下一个参数是将请求发送到的群集管理器的FQDN或IP的位置。最后一个参数告诉emake在Windows模式下运行。然后emake将在集群管理器所说的可用代理上同时运行所有7个任务。如果这个工具有一个多进程体系结构呢？这就是有趣的地方。这里有工具，如Pasopft的C/C++测试模式和流程分析工具，可以在单进程模式下运行，或者可以将其执行拆分成单独的进程，因为它通过C++项目工作。如果使用emake将其作为单个进程运行，则不会从中获得任何好处，因为插入的所有内容都是开销。但是，如果您告诉工具将其处理拆分为多个进程，则每当它必须调用一个底层可执行文件来执行部分分析时，优惠券返利，它都会生成一个新的进程。现在，如果你告诉emake去处理它，你不会得到任何好处。为什么？因为emake将把工具的整个运行过程发送给一个代理，所有的东西都将在这个代理上运行。然而，在这里，一个鲜为人知的CloudBees加速器组件可以来拯救它。（请注意，开发人员；这是您可以使用Accelerator发光的地方。）乘着超音速云通电Electrify和ElectrifyMon是Accelerator发行版附带的工具，但不需要任何额外的许可或费用。本质上，它们使您能够将进程发送给代理以进行并行化执行，但emake缺乏从以前运行中创建的历史中学习决策的能力，以及独立执行诸如找出依赖关系（或缺乏依赖关系）之类的事情。Electrify所做的（通过ElectrifyMon）是将自身注入到要执行的应用程序中，并监视进程的创建。当一个新的进程被创建时，它会将它与一个或多个进程进行比较，这些进程可以被拦截并发送给代理。如果没有匹配项，则进程在主机上按原样运行。这是一个你必须理解的关键点——你必须告诉Electrify它应该或不应该拦截哪个子进程。这样做的原因是，淘客采集，在默认情况下，Electrify会拦截所有子进程的创建并将其全部发送给代理。这可能会导致问题，毫无益处，或者更糟的是，减慢执行速度。让我们检查一下Pasopft的C/C++测试产品的具体例子。Pasopft的CPPestCLSI工具是命令行接口，开始分析。在大多数情况下，它将启动一个Java实例，然后调用cpptestcc，这是一个可执行文件，每个被分析的源代码文件启动一次。我们要做的是在cpptestcc运行ipro以分析include文件、ppro用于宏定义、cwc用于基于模式的代码分析时并行化cpptestcc的执行。最后一个组件flow analysis不能被划分和并行化，因为它的体系结构是多线程Java。因为我们无法将线程与应用程序分开，所以通常不会将其发送给代理。但是，由于我们目前无法指定只有部分cpptestcc运行可以并行化，而不能对其他运行进行并行化，所以我们并行化了所有cpptestcc进程。要执行并行化，可以使用如下命令行：通电--emake cm=--通电远程=cpptestcc--emake annodetail=basic--emake annoupload=1--cpptestcli-设置cpptestcli.settings.txt-输入cpptestscan.bdf-编译器vc_10_0第一个参数告诉Electrify它应该向哪个集群管理器发送请求。第二个参数告诉Electrify（或者更具体地说，ElectrifyMon）它应该在创建时拦截哪个进程。我们要告诉它的是，当cpptestcli调用cpptestcc时，它应该截获它并将其发送给代理以进行并行执行。并行化后，ipro、ppro和cwc也将在代理上运行。下面两个参数与emake的相同，用于注释目的。两个连字符"-"后面的所有内容都解释为