[发明专利]失败代码变化的识别

说明书

背景技术

软件开发生命周期使用持续集成（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还可包括中间代理、路由器、交换机、负载平衡器等。