CN104081359B - 失败代码变化的识别 - Google Patents

Abstract

公开了识别在具有多个代码变化的部署管线中的失败代码变化的方法。通过对多个代码变化运行一组测试来测试多个代码变化，直到多个代码变化的子集通过这组测试为止。每当子集未能通过这组测试时，多个代码变化中的至少一个从子集移除。基于通过这组测试的子集来确定失败代码变化。

Description

失败代码变化的识别

背景技术

软件开发生命周期使用持续集成（CI）和持续部署（DC）来减少在生产线中花费的时间代码变化。持续集成使从特定的源配置管理（SCM）工具接收代码变化、构造具有代码变化的可交付使用组件并测试组件的过程自动化。

附图说明

本公开的非限制性例子在参考附于其的附图阅读的下面描述中被描述，且并不限制权利要求的范围。在附图中，出现在多于一个附图中的其相同和相似的结构、元件或部分在它们出现所在的附图中通常用相同或相似的参考符号来标记。在附图中示出的部件和特征的尺寸主要为了陈述的方便和清楚而被选择，且不一定是按比例的。参考以下附图：

图1示出根据例子的网络环境；

图2-3示出根据例子的识别在部署管线中的失败代码变化的系统的方框图；

图4示出根据例子的可以与系统一起使用的计算机可读介质的方框图；

图5示出根据例子的识别在部署管线中的失败代码变化的过程的示意图；以及

图6-7示出根据例子的识别在部署管线中的失败代码变化的方法的流程图。

具体实施方式

在下面的详细描述中，参考形成其一部分的附图，且其中通过特定例子的方式进行示出，本公开可被实施在所述特定例子中。应理解，其它例子可被利用，且结构或逻辑变化可被做出而不偏离本公开的范围。因此下面的详细描述不应在限制性的意义上被理解，且本公开的范围由所附权利要求限定。

持续集成（CI）和持续部署（CD）使具有代码变化的代码组件的构造、测试和部署自动化。自动化在代码变化被交付到源配置管理（SCM）工具之后开始。持续集成使从SCM工具获取代码变化、构造可交付使用组件、例如执行对组件的构建和单元测试的过程自动化。持续部署通过将组件自动部署到测试环境中并对组件执行测试来扩展持续集成。持续集成促进由不同开发者进行的代码变化的进行中集成，并减小由于代码合并而引起的在测试环境中的失败的风险。

在例子中，提供了识别在具有多个代码变化的部署管线中的失败代码变化的方法。通过对多个代码变化运行一组测试来测试多个代码变化，直到多个代码变化的子集通过这组测试为止。每当子集未能通过这组测试时，多个代码变化中的至少一个从该子集被移除。基于通过这组测试的子集来确定失败代码变化。

短语“代码变化”指在软件应用的源代码中的变化。短语代码变化也可以指作为代码组件的部分的代码变化，代码组件被构造为持续集成过程的部分。

短语“部署管线”指在代码变化的队列上串行和/或并行地执行的一组动作。例如，部署管线可包括构建代码、执行单元测试、部署代码、运行自动化测试、对代码分级、运行端对端测试并部署代码以生产。

短语“一组测试”指在模拟环境中使用代码变化运行的测试。这组测试可包括测试代码变化的集成的单元测试和/或具有代码变化的功能测试。

短语“失败代码变化”指在测试期间的至少一个代码变化的失败。例如，多个代码变化可被组装或构建成组件，且单元测试可对代码变化被执行。如果一个代码变化具有错误和/或如果代码变化的组合不一起正确地工作，则单元测试可能失败。

图1示出根据例子的网络环境100。网络环境100包括连接测试设备12、部署设备14、客户端设备16和数据储存器18的链路10。测试设备12总地代表测试来自部署设备14的多个代码变化的任何计算设备或计算设备的组合。部署设备14代表接收代码变化并在部署管线中部署代码变化的计算设备。

客户端设备16代表配置成经由链路10与测试设备12和部署设备14交互的计算设备和/或计算设备的组合。交互可包括代表用户发送和／或传输数据，例如代码变化。交互还可包括接收数据，例如具有代码变化的软件应用。客户端设备16可以例如是包括使用户能够创建和/或编辑软件应用的代码的软件的个人计算设备。

测试设备12可在测试环境下对应用中的多个代码变化运行一组测试以集成多个代码变化来在软件应用中使用。这组测试和/或代码变化可存储在数据储存器18中。数据储存器18总地代表配置成存储在其功能的执行中可由测试设备12和部署设备14访问的数据的任何存储器。测试设备12的功能可经由链路10实现，链路10将测试设备12连接到部署设备14、客户端设备16和数据储存器18。

链路10总地代表经由电信链路、红外链路、射频链路或提供电子通信的任何其它连接器或系统的电缆、无线、光纤或远程连接中的一个或多个。链路10可至少部分地包括内联网、因特网或这两者的组合。链路10还可包括中间代理、路由器、交换机、负载平衡器等。

图2示出识别在具有多个代码变化的部署管线中的失败代码变化的系统100的方框图。参考图2，系统200包括测试引擎22和决策引擎24。测试引擎22总地代表对部署管线中的多个代码变化的子集执行一组测试的硬件和/或编程的组合。决策引擎24总地代表确定失败代码变化的硬件和/或编程的组合。决策引擎24还指示测试引擎22执行这组测试并从该子集移除多个代码变化中的至少一个，直到子集通过这组测试为止。决策引擎24基于从通过这组测试的子集移除的至少一个代码变化来确定失败代码变化。

图3示出根据进一步例子的在网络环境100中的系统200的方框图。图3所示的系统200包括测试设备12、部署设备14和数据储存器18。测试设备12被示为包括测试引擎22和决策引擎24。测试设备12连接到从客户端设备16接收代码变化36的部署设备14。使用来自数据储存器18的测试或一组测试38在测试设备12中测试代码变化36。在代码变化通过这组测试38之后，部署设备14经由部署管线部署经测试的代码变化36。

测试引擎22对部署管线中的多个代码变化36的子集执行一组测试38。决策引擎24指示测试引擎22执行这组测试38。决策引擎24还从多个代码变化36的子集移除多个代码变化36中的至少一个，直到该子集通过这组测试38为止。决策引擎24可具有移除代码变化36的能力和/或可指示例如管线引擎32（下面讨论）的单独的引擎移除代码变化36。

此外，决策引擎24基于从通过这组测试38的子集移除的至少一个代码变化36确定失败代码变化。例如，决策引擎24可识别从子集移除的多个代码变化36中的至少一个以确定失败代码变化。而且，决策引擎24可执行比较。例如，当子集在通过这组测试38之前未能通过这组测试38时，决策引擎24可通过比较包含在通过这组测试38的子集中的至少一个代码变化36与包含在未能通过这组测试38的子集中的至少一个代码变化36来确定失败代码。决策引擎24还可自动传输识别失败代码变化的消息。

测试设备12还被示为包括管线引擎32。管线引擎32总地代表创建在部署管线中的多个代码变化36的子集和/或从该子集移除多个代码变化中的至少一个的硬件和/或编程的组合。例如，管线引擎32可从决策引擎24接收指令以移除多个代码变化36中的至少一个。管线引擎32也可从多个代码变化36创建多个并行测试子集。多个并行测试子集中的每个包括多个代码变化36的不同排列。测试引擎22可同时测试多个并行测试子集中的每个以确定多个并行测试子集中的哪个通过这组测试38。可基于处理器和/或计算资源的能力来执行同时测试。

部署设备14包括部署引擎34。部署引擎34总地代表在测试环境下在应用中测试之后部署代码变化36的硬件和/或编程的组合。部署设备14连接到数据储存器18。数据储存器18例如是存储代码变化36和这组测试38的数据库。部署引擎34可与测试引擎22、决策引擎24和管线引擎36一起工作以测试在部署管线中的多个代码变化36的集成。

图4示出根据例子的可以与图2的系统200一起使用的计算机可读介质的方框图。在图4中，测试设备12被示为包括存储器41、处理器42和接口43。处理器42总地代表配置成执行存储在存储器41中的程序指令以执行各种指定的功能的任何处理器。接口43总地代表使测试设备12能够经由链路10与部署设备14通信的任何接口，如在图1和3中所示的。

存储器41被示为包括操作系统44和应用45。操作系统44代表当由处理器42执行时用作平台的程序的集合，应用45可在该平台上运行。操作系统43的例子包括微软的Windows®和Linux®的各种版本。应用45代表当由处理器42执行时用作识别失败代码变化的应用的程序指令。例如，图4示出测试模块46、决策模块47和管线模块48作为存储在测试设备12的存储器41中的可执行程序指令。

参考回图2-3，测试引擎22、决策引擎24和管线引擎32被描述为硬件和/或编程的组合。如图4所示，硬件部分可包括处理器42。编程部分可包括操作系统44、应用45和/或其组合。例如，测试模块46代表当由处理器42执行时引起图2-3的测试引擎22的实现的程序指令。决策模块47代表当由处理器42执行时引起图2-3的决策引擎24的实现的程序指令。管线模块48代表当由处理器42执行时引起图2-3的管线引擎32的实现的程序指令。

测试模块46、决策模块47和管线模块48的编程可以是存储在包括有形存储器介质的存储器41上的处理器可执行的指令，且硬件可包括用于执行指令的处理器42。存储器41可存储程序指令，其当由处理器42执行时使处理器42执行程序指令。存储器41可集成在与处理器42相同的设备中，或它可以是单独的，但是对于该设备和处理器42是可访问的。

在一些例子中，程序指令可以是可由处理器42执行来使用系统200执行方法的安装封装的部分。存储器41可以是便携式介质，例如CD、DVD或闪速驱动器或由服务器维持的存储器，安装封装可从该服务器被下载和安装。在一些例子中，程序指令可以是已经安装在服务器上的一个或多个应用的部分。在进一步的例子中，存储器41可包括集成存储器，例如硬盘驱动器。

图5示出根据例子的识别失败代码变化的过程的示意图500。图5示出测试设备12和部署设备14。部署设备14分成持续集成部分50和持续部署部分51。持续集成部分50包括构建50A和单元测试50B步骤。构建50A步骤创建包括代码变化的组件。持续部署部分51执行组件的自动化测试，其确定具有代码变化的组件何时就绪以被发布到软件应用中的生产中。例如，部署管线53的持续部署部分51可使用下列步骤将具有代码变化的组件部署到生产：部署到测试51A、应用编程接口/功能测试51B、部署到分级测试51C、端对端/性能测试51D和对部署到生产51E的验证。

参考持续集成部分50，代码变化集成在组件中可被自动化，这在单元测试50B的结果指示具有代码变化的测试或一组测试是可接受的或通过测试时将组件发送到持续部署部分51。然而，当组件未通过单元测试时，引起失败的代码变化使用手动和耗时过程而被确定。如所示的测试设备12可允许导致失败的代码变化的自动化识别。例如，当单元测试50B失败时，测试设备12被启动。测试设备12然后从部署设备14中的部署管线53复制52在例如管线引擎32中的代码变化。组件被重建54有从组件移除55的至少一个代码变化。通过运行57与在重建54的组件上的单元测试50B相同或相似的一组测试来执行单元测试56。组件可被重建，且单元测试在例如测试引擎22中被执行。

当单元测试56失败时，组件被重建54有被移除55的不同代码变化，且单元测试56被再次执行。重建54和单元测试56重复或继续，直到组件在单元测试56中通过这组测试57。接着基于在通过这组测试57的组件中的代码变化来确定58失败代码变化。例如决策引擎24可比较通过这组测试的组件中的代码变化与未能通过这组测试的最后一个组件中的代码变化。失败代码变化可接着作为消息59被自动传输到开发者和/或管理员。失败代码变化的检测58识别包含至少一个失败代码变化的单个代码变化和/或一组或多个代码变化。

图6示出根据例子的识别在具有多个代码变化的部署管线中的失败代码变化的方法的流程图600，所述方法例如处理器实现的方法。在块62中，在部署管线中的多个代码变化在测试环境下在应用中被测试，例如在测试引擎中被测试。测试包括对多个代码变化运行一组测试，直到多个代码变化的子集通过这组测试为止。测试还包括每当子集未能通过这组测试时从子集移除多个代码变化中的至少一个。

可基于多个代码变化中的至少一个放置在源配置管理工具中时的时间来选择所移除的多个代码变化中的至少一个。例如，当每个代码变化通过源配置管理工具被提交时它可接收时间戳，且与时间戳相关的数据可由管线引擎使用来确定哪个代码变化被移除和/或提供识别信息，例如提交代码变化的开发者。额外的数据也可与每个代码变化相关，并可类似地用于确定哪个代码变化被移除。此外，预定百分比的多个代码变化可从子集移除，直到子集通过这组测试为止。例如，子集可分成两半，直到子集通过这组测试为止。在例子中，如果在测试期间从子集移除三次一半代码变化，则到子集通过这组测试时为止子集如下：测试1）子集中的所有代码变化，测试2）子集中的一半代码变化，测试3）子集中的四分之一的代码变化，以及测试4）子集中的八分之一的代码变化。

在块64中基于通过这组测试的子集确定失败代码变化。决策引擎可做出确定并识别失败代码变化。失败代码变化的确定可包括从子集移除的多个代码变化中的至少一个的识别。失败代码变化的确定还可包括通过这组测试的子集中的多个代码变化中的至少一个与未能通过这组测试的子集中的多个代码变化中的至少一个的比较。参考回其中每当子集未能通过单元测试时一半代码变化被移除的例子，自动化确定失败代码变化在测试3和4之间移除的八分之一代码变化中。在持续集成期间使用自动化确定节省了时间和资源。

该方法还可复制在部署管线中的多个代码变化以创建子集。而且，多个代码变化可被复制以创建多个并行测试子集，多个并行测试子集中的每个具有多个代码变化的不同排列。多个并行测试子集可被同时测试以确定多个并行测试子集中的哪个通过这组测试。通过这组测试的多个并行测试子集然后被比较以确定失败代码变化。

图7示出识别在具有多个代码变化的部署管线中的失败代码变化的方法的流程图700，该方法例如处理器实现的方法。例如，该方法可以是存储在计算机可读介质上的指令，其在由处理器执行时使处理器执行该方法。在块72中，在部署管线中、例如在部署引擎中创建多个代码变化的子集。在块74中测试子集。例如，测试可由对子集运行一组测试的测试设备执行，并从子集移除多个代码变化中的至少一个，直到子集通过这组测试为止。在块76中识别失败代码变化。基于从子集移除的多个代码变化中的至少一个来识别失败代码变化。

图1-7帮助说明根据例子的架构、功能和操作。例子示出各种物理和逻辑部件。所示的各种部件至少部分地被定义为程序、编程或程序指令。每个这样的部件、其部分或其各种组合可整体或部分地代表包括一个或多个可执行指令来实现任何指定的逻辑功能的代码部分、模块或段。每个部件或其各种组合可代表实现指定的逻辑功能的电路或多个互连的电路。

例子可在任何计算机可读介质中实现，以由或结合指令执行系统使用，指令执行系统例如基于计算机/处理器的系统或ASIC（专用集成电路）或可从计算机可读介质取出或得到逻辑并执行其中包含的指令的其它系统。“计算机可读介质”可以是可包含、存储或维持程序和数据以由或结合指令执行系统使用的任何介质。计算机可读介质可包括很多物理介质中的任一个，例如，诸如电子、磁性、光、电磁或半导体介质。适当的计算机可读介质的更具体的例子包括但不限于便携式磁计算机磁盘，例如软盘或硬盘驱动器、随机存取存储器（RAM）、只读存储器（ROM）、可擦除可编程只读存储器或便携式光盘。

虽然图6-7的流程图示出特定的执行顺序，但是执行顺序可不同于所示的执行顺序。例如，块的执行顺序可相对于所示的顺序被弄乱。此外，连续示出的块可被同时或部分同时地执行。所有这样的变型在本发明的范围内。

本公开使用其例子的非限制性详细描述被描述，且并不意图限制本公开的范围。应理解，关于一个例子描述的特征和/或操作可与其它例子一起使用，且不是本公开的所有例子都具有在特定的附图中示出或关于例子之一描述的所有特征和/或操作。本领域的技术人员将想到所描述的例子的变型。此外，术语“包括”、“包含”、“具有”及其词形变化当在本公开和/或权利要求中被使用时应意指“包括但不一定限于”。

注意，上述例子中的一些可包括可能对本公开不是必不可少且意图是示例性的结构、动作或结构和动作的细节。如在本领域中已知的，本文描述的结构和动作可由执行相同功能的等同物代替，即使结构或动作是不同的。因此，本公开的范围仅由如在权利要求中使用的元件和限制来限制。

Claims (15)

1.一种识别在具有多个代码变化的部署管线中的失败代码变化的计算机实现的方法，所述方法包括：

在测试环境下在应用中测试在所述部署管线中的所述多个代码变化，测试包括：

对所述多个代码变化运行一组测试，直到所述多个代码变化的子集通过所述一组测试为止，以及

每当子集未能通过所述一组测试时，从子集移除所述多个代码变化中的至少一个；以及

基于通过所述一组测试的子集来确定失败代码变化；

其中，所述部署管线是在所述多个代码变化的队列上串行和/或并行地执行的一组动作。

2.如权利要求1所述的方法，其中确定失败代码变化包括识别从子集移除的所述多个代码变化中的至少一个。

3.如权利要求1所述的方法，其中确定失败代码变化包括比较通过所述一组测试的子集中的所述多个代码变化中的至少一个与未能通过所述一组测试的子集中的所述多个代码变化中的至少一个。

4.如权利要求1所述的方法，其中移除所述多个代码变化中的至少一个还包括基于所述多个代码变化中的至少一个放置在源配置管理工具中时的时间来选择要移除的所述多个代码变化中的至少一个。

5.如权利要求1所述的方法，其中移除所述多个代码变化中的至少一个还包括从子集移除预定百分比的所述多个代码变化，直到子集通过所述一组测试为止。

6.如权利要求1所述的方法，还包括复制在所述部署管线中的所述多个代码变化中的至少一个以创建子集。

7.如权利要求1所述的方法，还包括从所述部署管线中的所述多个代码变化创建多个并行测试子集，所述多个并行测试子集中的每个包括所述多个代码变化的不同排列。

8.如权利要求7所述的方法，其中测试所述多个代码变化还包括：

同时测试所述多个并行测试子集中的每个以确定所述多个并行测试子集中的哪个通过所述一组测试；以及

比较通过所述一组测试的多个并行测试子集以确定失败代码变化。

9.一种识别在具有多个代码变化的部署管线中的失败代码变化的系统，所述系统包括：

测试引擎，用于对在所述部署管线中的所述多个代码变化的子集执行一组测试；以及

决策引擎，用于：

指示所述测试引擎执行所述一组测试，

从所述多个代码变化的子集移除所述多个代码变化中的至少一个，直到子集通过所述一组测试为止，以及

基于从通过所述一组测试的子集移除的至少一个代码变化来确定失败代码变化；

其中，所述部署管线是在所述多个代码变化的队列上串行和/或并行地执行的一组动作。

10.如权利要求9所述的系统，其中所述决策引擎通过比较以下来确定失败代码变化：包含在通过所述一组测试的子集中的至少一个代码变化与当子集在通过所述一组测试之前未能通过所述一组测试时包含在未能通过所述一组测试的子集中的至少一个代码变化。

11.如权利要求9所述的系统，还包括管线引擎，用于从子集移除所述多个代码变化中的至少一个。

12.如权利要求11所述的系统，其中所述管线引擎从所述多个代码变化创建多个并行测试子集，所述多个并行测试子集中的每个包括所述多个代码变化的不同排列。

13.如权利要求12所述的系统，其中所述测试引擎同时测试所述多个并行测试子集中的每个以确定所述多个并行测试子集中的哪个通过所述一组测试。

14.如权利要求9所述的系统，其中所述决策引擎自动传输识别失败代码变化的消息。

15.一种识别在具有多个代码变化的部署管线中的失败代码变化的方法，所述方法包括：

创建在所述部署管线中的所述多个代码变化的子集；

测试子集，其中测试包括：

对子集运行一组测试，以及

从子集移除所述多个代码变化中的至少一个，直到子集通过所述一组测试为止；以及

基于从子集移除的所述多个代码变化中的至少一个来识别失败代码变化；

其中，所述部署管线是在所述多个代码变化的队列上串行和/或并行地执行的一组动作。