CN111382049A - 代码提交方法、装置及电子设备 - Google Patents

Abstract

本发明实施例提供一种代码提交方法、装置及电子设备，其中，方法包括：获取待向代码库的指定代码分支提交的增量代码；对所述增量代码进行预验证，所述预验证包括将当前所述代码库中的基线代码与所述增量代码进行合并，并对合并后的代码通过预置测试集代码进行集成功能测试；提交预验证通过的增量代码至所述代码库的指定代码分支。本发明实施例的方案，通过向目标代码分支提交已经过集成功能测试的代码，从而避免代码提交后导致的主干代码集成功能质量不达标的问题，使得主干代码随时处于可交付状态。

Description

代码提交方法、装置及电子设备

技术领域

本申请涉及通信技术领域，尤其涉及一种代码提交方法、装置及电子设备。

背景技术

目前，在软件开发过程中，一般由多个项目组在同一个项目上并行开发，开发完成后，需要将分支代码合并至主干代码中。在需要多人协作在同一个代码分支上提交代码的时候，由于开发人员本地开发环境的差异，错误的代码合并，不严格的验证过程等人为或客观环境问题，可能造成提交代码后导致的主干代码引入了不达标的代码，进而需要消耗很长时间对合并后的主干代码进行集成功能测试，测试通过后才能发布上线，延长了被开发软件的上线周期。

虽然，在如gitlab的merge request的方案中，允许代码合并前进行代码审查(如code review)，但审查内容主要针对的是代码内容合并中的冲突验证，仍不能避免代码提交后导致的主干代码引入了集成功能不达标的代码的问题。

发明内容

本发明提供了一种代码提交方法、装置及电子设备，通过向目标代码分支提交已经过集成功能测试的代码，从而避免代码提交后导致的主干代码集成功能质量不达标的问题，使得主干代码随时处于可交付状态。

为达到上述目的，本发明的实施例采用如下技术方案：

第一方面，提供了一种代码提交方法，包括：

获取待向代码库的指定代码分支提交的增量代码；

对所述增量代码进行预验证，所述预验证包括将当前所述代码库中的基线代码与所述增量代码进行合并，并对合并后的代码通过预置测试集代码进行集成功能测试；

提交预验证通过的增量代码至所述代码库的指定代码分支。

第二方面，提供了一种代码提交装置，包括：

代码获取模块，用于获取待向代码库的指定代码分支提交的增量代码；

代码预验证模块，用于对所述增量代码进行预验证，所述预验证包括将当前所述代码库中的基线代码与所述增量代码进行合并，并对合并后的代码通过预置测试集代码进行集成功能测试；

代码提交模块，用于提交预验证通过的增量代码至所述代码库的指定代码分支。

第三方面，提供了一种电子设备，包括：

存储器，用于存储程序；

处理器，耦合至所述存储器，用于执行所述程序，所述程序运行时执行本发明提供的所述代码提交方法。

本发明提供了一种代码提交方法、装置及电子设备，在获取待向代码库的指定代码分支提交的增量代码后，先对增量代码进行预验证，该预验证包括将当前代码库中的基线代码与增量代码进行合并，并对合并后的代码通过预置测试集代码进行集成功能测试；然后，提交预验证通过的增量代码至代码库的指定代码分支。本方案中将代码分支提交和集成测试自动化流程进行无缝对接，实现对目标分支代码在可交付功能层面的质量监控和运维自动化，避免代码提交后导致的主干代码集成功能质量不达标的问题，使得主干代码随时处于可交付状态。

上述说明仅是本申请技术方案的概述，为了能够更清楚了解本申请的技术手段，而可依照说明书的内容予以实施，并且为了让本申请的上述和其它目的、特征和优点能够更明显易懂，以下特举本申请的具体实施方式。

附图说明

通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本申请的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：

图1为本发明实施例的代码提交逻辑架构图；

图2为本发明实施例的代码提交方法流程图一；

图3为本发明实施例的预验证阶段的处理方法流程图一；

图4为本发明实施例的预验证阶段的处理方法流程图二；

图5为本发明实施例的代码提交阶段的处理方法程图一；

图6为本发明实施例的代码提交阶段的处理方法程图二；

图7为本发明实施例的代码提交方法流程图二；

图8为本发明实施例的代码提交装置结构图一；

图9为本发明实施例的代码提交装置结构图二；

图10为本发明实施例的代码提交装置结构图三；

图11为本发明实施例的代码提交装置结构图四；

图12为本发明实施例的电子设备的结构示意图。

具体实施方式

下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。

技术术语解释：

代码库：指保存、管理代码的数据仓库，通常由专门的代码管理工具如git，svn，cvs实现代码管理；

代码分支：指的是代码库上针对某一类功能集合而存在的代码结合；

基线(baseline):基线版本是指某一个代码分支的版本，在这个版本上的代码已经通过了某种可置信的质量测试回归，具有符合预期的、完备的已验证功能。实际上，如果一个系统只有一个工程(提供服务)，那这里的基线就是指工程主分支的某个经过验证的代码版本；如果一个系统里有多个工程(提供服务)，那这里的基线是指各工程主分支版本的组合。

补丁(patch):指在基线版本的基础上，额外增减的代码内容；本方案中也泛指提交到代码分支上的增量代码。

本发明实施例改善了现有技术中，在多人协作在同一个代码分支上提交增量代码后，所导致的主干代码引入了不达标的代码，进而需要消耗很长时间对合并后的主干代码进行集成功能测试的缺陷，其核心思想是，将代码提交过程分为两个阶段：预验证阶段和代码提交阶段。在预验证阶段，当开发者向代码库中的指定代码分支提交增量代码时，先对增量代码进行预验证，该预验证包括将当前代码库中的基线代码与增量代码进行合并，并对合并后的代码通过预置测试集代码进行集成功能测试。然后，在代码提交阶段，将预验证通过的增量代码提交至代码库的指定代码分支，从而避免代码提交后导致的主干代码集成功能质量不达标的问题，使得主干代码随时处于可交付状态。

基于上述代码提交的方案思想，图1为本发明实施例提供的代码提交逻辑架构图。该逻辑架构中涉及以下几个主体：

开发者：编写软件代码的人，本方案中开发者主要向调度分发服务器发起针对所编写的增量代码(以下用补丁patch作为增量代码为例进行说明)的预验证、以及提交代码请求。

调度分发服务器：与开发者、调度数据库、后台验证集群、代码托管服务器分别进行交互，在多方之间实现操作协调调度，从而完成整个代码提交过程，包括对待提交的patch的预验证、代码提交两个阶段。

调度数据库：用于存储预验证阶段、代码提交阶段中所需的操作数据以及两个阶段中产生的状态数据。比如，当前代码库的基线版本、开发者提交的patch的信息、预验证结果信息、代码提交阶段所需的校验信息等。

后台验证集群：用于对调度分发服务器发布的patch进行预验证，即将当前代码库中的基线代码与开发者提交的patch进行合并，并对合并后的代码通过预置测试集代码进行集成功能测试。后台验证集群的部署可以是由物理机或者容器环境搭建实现。

代码托管服务器：用于管理基线代码、测试集代码。主要操作包括：向调度分发服务器同步当前基线版本；接收调度分发服务器上传的已通过预验证的patch；向后台验证集群提供集成功能测试所需的基线代码和测试集代码。

代码提交逻辑包括：

代码预验证阶段：开发者向调度分发服务器提交patch，发起预验证；调度分发服务器将patch发布给后台验证集群进行预验证；后台验证集群从代码托管服务器下载当前代码库的基线代码以及测试集代码，将当前代码库中的基线代码与开发者提交的patch进行合并，并对合并后的代码通过预置测试集代码进行集成功能测试，最后将预验证结果返回至调度分发服务器，进而反馈给开发者；调度分发服务器记录本次预验证的相关信息至调度数据库，同时产生用于代码提交阶段对patch进行验证的校验信息，该校验信息也被存储至调度数据库。

代码提交阶段：开发者向调度分发服务器提交通过预验证的patch，发起代码提交请求；调度分发服务器基于之前产生的校验信息对开发者提交的patch进行校验；调度分发服务器提交验证通过的patch至代码库的指定代码分支。

进一步地，上述校验信息可包括：“基线版本信息+patch全文内容hash值+代码提交时间窗口”。验证内容包括：patch预验证时所用的基线版本和当前代码分支最新的基线版本是否相同；根据Patch内容计算hash值，patch的内容hash结果是否和调度数据库里的记录相同，以确认本次提交的代码和预验证时的代码内容是否一致；验证代码提交的时间窗口是否合法。

下面通过多个实施例来进一步说明本申请的技术方案。

实施例一

基于上述代码提交的方案思想，如图2所示，其为本发明实施例示出的代码提交方法流程图一，该方法可通过图1中所示的调度分发服务器协调执行完成。如图2所示，该代码提交方法包括如下步骤：

S210，获取待向代码库的指定代码分支提交的增量代码。

开发者在本地开发环境中完成针对代码库中某个代码分支上的功能更新而产生增量代码后，可将增量代码提交到代码库相应的代码分支上实现分支合并。

其中，增量代码可以泛指待提交到代码分支上的任何功能类型的代码，以下将以补丁patch作为增量代码为例进行说明。

S220，对增量代码进行预验证，预验证包括将当前代码库中的基线代码与增量代码进行合并，并对合并后的代码通过预置测试集代码进行集成功能测试。

现有技术中，普遍采用在将patch提交到目标代码分支后，对主干代码进行集成测试。这样很可能会导致主干代码引入了不达标的代码，进而需要消耗很长时间对合并后的主干代码进行集成功能测试，使得主干代码不能随时处于可交付状态，耽误被开发软件的整体上线时间。

本方案与现有技术的区别在于，在提交patch到指定代码分支之前，先对patch执行预验证，该预验证内容包括：将当前代码库中的基线代码与patch进行合并，并对合并后的代码通过预置测试集代码进行集成功能测试。

其中，测试集体现的是对目标代码(这里指合并了patch后的代码分支的代码)功能维度上的度量，需要以代码的形式固定下来，可自动化执行；出于时间考虑，测试集的执行时间必须控制在可接受的范围。

在对合并后的代码进行集成功能测试并且测试通过后，则可判断出待提交的patch符合代码分支合并后的功能维度上的度量标准，否则，不符合功能维度上的度量标准，即使patch被提交到指定代码分支上，也会像现有技术中，再次经历集成功能测试的过程。另外，先提交代码，后执行集成功能测试的这种方案一个很严重的影响是：一旦提交了功能不达标的patch到指定代码分支，新的基线版本就会产生，其他开发者就会基于新的基线版本继续编写代码，这样无疑加剧了目标代码的不达标程度，也增大了后续集成功能测试的测试难度，延长了软件开发周期。

因此，本方案采取在提交patch之前，先对patch进行预验证，只有通过预验证的patch才有机会被提交到指定代码分支，保证了代码分支符合预定功能标准。

S230，提交预验证通过的增量代码至代码库的指定代码分支。

将预验证通过的patch提交到代码库的指定代码分支，形成新的基线版本，可以实现将代码提交过程和对代码分支的集成功能测试过程进行无缝对接，实现对目标分支代码在可交付功能层面的质量监控和运维自动化。

本发明提供的代码提交方法，在获取待向代码库的指定代码分支提交的增量代码后，先对增量代码进行预验证，该预验证包括将当前代码库中的基线代码与增量代码进行合并，并对合并后的代码通过预置测试集代码进行集成功能测试；然后，提交预验证通过的增量代码至代码库的指定代码分支。本方案中将代码分支提交和集成测试自动化流程进行无缝对接，实现对目标分支代码在可交付功能层面的质量监控和运维自动化，避免代码提交后导致的主干代码集成功能质量不达标的问题，使得主干代码随时处于可交付状态。

实施例二

本实施例所示的方法步骤可视为对增量代码的预验证阶段进行的方案拓展，主要是在预验证通过后，生成校验信息以及执行一些关联设置，以方便后续在代码提交阶段能够将增量代码安全、顺利提交到指定代码分支。

首先，如图3所示，为本发明实施例的预验证阶段的处理方法流程图一。在实施例一所示方法的基础上，在对增量代码通过预验证之后还包括生成提交代码阶段所需的校验信息。如图3所示，在步骤S220之后，还可执行如下步骤：

S310，如果预验证通过，则生成用于提交预验证通过的增量代码至代码库的指定代码分支的校验信息。

开发者在预验证阶段提交patch，可能并不想马上将patch提交到指定代码分支进行合并，而只是通过预验证环节对自己编写的代码执行一次集成功能测试，以检测合并后的目标代码功能是否达到预期标准。此时，调度分发服务器可以针对预验证通过的patch生成相应的校验信息，以对后续待提交的预验证通过的patch至代码库的指定代码分支时，对patch进行验证，验证通过的patch可以被合并到指定代码分支，以产生新的基线版本。

这里需要说明的是，校验信息的内容以及验证方式在本方案中并不做限定，可以根据具体的提交代码阶段可能遇到的各种问题环境进行合理设置。

S320，向本次提交增量代码的开发者反馈预验证结果信息，预验证结果信息中包括在预验证通过后增加的，与校验信息关联的校验令牌。

在一次预验证过程执行完成后，可以向本次提交patch验证的开发者反馈预验证结果信息，比如本次预验证通过或者未通过的信息内容。另外，在预验证通过所对应的预验证结果信息中还可增加与之前生成的校验信息关联的校验令牌，该校验令牌一方面可以表明所指向的patch在预验证阶段是被验证通过的，另一方面也可作为该patch在整个代码提交过程中的全局变量。

例如，当开发者提交patch，且同时提交了校验令牌，那么调度分发服务器默认对当前patch执行代码提交阶段的相关处理；当开发者提交patch，而没有提交校验令牌，那么调度分发服务器默认对当前patch执行预验证阶段的相关处理。另外，作为本次提交的patch对应的全局变量，通过该校验令牌可以追溯该patch对应的如校验信息等所属于当前patch的相关内容。

进一步地，如图4所示，在图3所示方法的基础上，为了在需要多人协作在同一个代码分支上提交代码的时候，防止多个提交代码的行为造成目标代码的功能冲突，在每个patch预验证通过后，还包括执行如下步骤：

步骤S410，如果预验证通过，则设置代码提交时间窗口；该代码提交时间窗口用于在对应时间内锁定指定代码分支，仅允许被分配在代码提交时间窗口内提交的增量代码有权限对指定代码分支进行解锁；

相应的，在针对patch产生的校验信息中包括用于提交增量代码至代码库的指定代码分支的代码提交时间窗口。

这样，当开发者在相应的代码提交时间窗口提交patch以及之前分配的校验令牌后，调度分发服务器就可以根据校验令牌追溯之前预验证阶段生成的校验信息，并从校验信息中解析出该patch对应的代码提交时间窗口，如果该代码提交时间窗口与当前时间一致，则调度分发服务器触发解锁指定代码分支，完成patch的代码提交。

针对每个通过预验证的patch，调度分发服务器都会生成一个代码提交时间窗口供该patch完成提交过程，且每个代码提交时间窗口之间无重合部分。

进一步地，在代码提交阶段，不仅要保证被提交到同一个代码分支上的多个patch之间不能发生提交冲突，还要保证被提交的patch在合并到指定代码分支后和该patch在预验证阶段的合并结果的一致性。因此，在校验信息中还可包括：在预验证阶段对应的增量代码的内容验证信息、基线版本信息。

其中，上述内容验证信息可以是在预验证阶段，基于当时预验证通过的patch内容形成的内容验证信息，比如patch内容的哈希值(hash)，该内容验证信息可以对patch在预验证阶段和代码提交阶段是否为同一内容进行验证。校验信息中的基线版本信息则对应为patch在预验证阶段时，对应的代码库中当时的基线版本。

进一步地，在对增量代码进行预验证之后还可包括：如果预验证通过，则释放预验证环境。

在对patch执行预验证且通过验证后，调度分发服务器可释放预验证环境，节省测试资源；当然，如果对patch执行预验证且未通过验证，那么调度分发服务器可暂时不释放预验证环境，以等待开发者重新提交patch后，对重新提交的patch继续执行预验证，节省了预验证环境的加载过程，提高预验证效率。

该实施例在图2所示实施例基础上，进一步地，在对增量代码进行预验证之后，如果预验证通过，则生成用于提交预验证通过的增量代码至代码库的指定代码分支的校验信息；向本次提交增量代码的开发者反馈预验证结果信息，该预验证结果信息中包括在预验证通过后增加的，与校验信息关联的校验令牌。通过在增量代码通过预验证后，生成用于在代码提交阶段对待提交的增量代码进行验证的校验信息，并在预验证结果信息中增加校验令牌，从而为后续代码提交阶段，为提交增量代码至指定代码分支提供便利，并保证正确提交，使得合并后的目标代码的功能达到预期标准。

进一步地，在对增量代码进行预验证之后，如果预验证通过，则设置代码提交时间窗口；该代码提交时间窗口用于在对应时间内锁定指定代码分支，仅允许被分配在代码提交时间窗口内提交的增量代码有权限对指定代码分支进行解锁；相应的，在校验信息中包括用于提交增量代码至代码库的指定代码分支的代码提交时间窗口，从而保证被提交到同一个代码分支上的多个增量代码之间不会发生提交冲突，从而避免造成同一代码分支上的功能冲突。

进一步地，上述校验信息中还包括：在预验证阶段对应的增量代码的内容验证信息、基线版本信息，以对代码提交阶段的增量代码在内容以及所适用的基板版本进行验证，确保预验证阶段和代码提交阶段中目标代码合并结果的一致性。

实施例三

本实施例所示的方法步骤可视为对增量代码的代码提交阶段进行的方案细化，主要是基于实施例二中示出的预验证阶段的执行内容的拓展，对代码提交阶段的相对应的执行过程进行具体描述。

首先，如图5所示，为本发明实施例的代码提交阶段的处理方法流程图一。在图3所示方法的基础上，本实施例对增量代码的提交过程进行细化。如图5所示，上述步骤S230可包括执行如下步骤：

S510，接收预验证通过的增量代码的提交请求，提交请求中携带校验令牌。

开发者在预验证阶段提交patch，可能并不想马上将patch提交到指定代码分支进行合并，而只是通过预验证环节对自己编写的代码执行一次集成功能测试，以检测合并后的目标代码功能是否达到预期标准。此时，调度分发服务器可以针对预验证通过的patch生成相应的校验信息，以对后续待提交的预验证通过的patch至代码库的指定代码分支时，对patch进行验证，验证通过的patch可以被合并到指定代码分支，以产生新的基线版本。在向开发者反馈的预验证结果信息中还包括与上述校验信息关联的校验令牌。

开发者可在所编写的patch通过预验证，且获取到校验令牌之后，向调度分发服务器发起patch的提交请求，以申请将patch合并到指定代码分支。

S520，根据与校验令牌关联的校验信息，对增量代码进行验证。

当开发者提交patch，且同时提交了校验令牌，那么调度分发服务器默认对当前patch执行代码提交阶段的相关处理。调度分发服务器通过校验令牌与校验信息的关联性可以追溯该patch对应的校验信息，并利用校验信息对本次提交的patch的提交合法性进行验证。

在之前的内容中已说明，校验信息的内容以及验证方式在本方案中并不做限定，可以根据具体的提交代码阶段可能遇到的各种问题环境进行合理设置。如图6所示：

例如，当校验信息中包括代码提交时间窗口，则根据校验信息对增量代码进行验证时可执行以下步骤：

步骤S610，判断当前增量代码的提交时间是否位于代码提交时间窗口中，如果位于，则确定针对代码提交时间窗口对应的校验项上增量代码通过验证。

例如，当实际开发者提交预验证通过的patch的时间点位于调度分发服务器预先分配给该patch的代码提交时间窗口中时，则认为代码提交时间窗口当前是合法有效的，patch在代码提交时间窗口这个校验项上是验证通过的，patch可以被提交到指定代码分支。而如果提交预验证通过的patch的时间点位于调度分发服务器预先分配给该patch的代码提交时间窗口以外，那么则认为代码提交时间窗口当前是不合法，patch在代码提交时间窗口这个校验项上是验证不通过的，patch不能被提交到指定代码分支。

又例如，当校验信息中包括在预验证阶段对应的增量代码的内容验证信息以及基线版本信息，则根据校验信息对增量代码进行验证时可执行以下步骤：

S620，根据内容验证信息对增量代码的内容进行验证，如果验证通过，则确定针对增量代码的内容对应的校验项上增量代码通过验证；

例如，当内容验证信息为根据Patch内容计算的hash值，可以对当前开发者提交的patch的内容再次进行哈希计算得到hash值，并将该hash值与校验信息中记录的hash值进行比较，如果相同，则确认本次提交的patch和预验证时的patch内容一致，patch在内容这个校验项上是验证通过的，patch可以被提交到指定代码分支。

S630，判断当前代码库中基线版本是否与校验信息中记录的基线版本相同，如果相同，则确定针对基线版本对应的校验项上增量代码通过验证。

理论上，如果校验信息中包括上述三个校验项，即：代码提交窗口时间+patch的内容hash值+patch预验证时的基线版本，且patch在所有校验项上全部通过验证，则可以认为本次提交的patch合法、有效，可以被提交到指定代码分支。而在实际操作中，可以按：代码提交窗口时间→patch预验证时的基线版本→patch的内容hash值的顺序逐一对patch进行验证，以减少验证的计算复杂度，因为计算patch的内容hash值是很耗时和耗费计算资源的，而一旦前两个校验项任一个没有验证通过时，都可以直接判定针对patch的验证未通过，而无需再进行patch的内容校验，从而快速完成对patch的验证过程。

S530，提交验证通过的增量代码至代码库的指定代码分支。

如果待提交的patch通过了校验信息中规定的所有校验项的验证，则确定验证通过，调度分发服务器可以将该patch提交到指定代码分支上。

进一步地，基于校验信息中代码提交时间窗口的设置，在提交增量代码(patch)时，需要在代码提交时间窗口内解锁指定代码分支，然后提交增量代码(patch)至指定代码分支。

Patch一旦完成提交，指定代码分支自然被解锁，而如果在超出代码提交时间窗口规定的时间段，调度分发服务器仍没有接收到开发者提交的Patch，则此时指定代码分支也会被解锁。解锁后的代码分支可以继续接收其他开发者提交的Patch。

该实施例在图3、图4所示实施例基础上，进一步地，通过接收预验证通过的增量代码的提交请求，提交请求中携带校验令牌；并根据与校验令牌关联的校验信息，对增量代码进行验证；提交验证通过的增量代码至代码库的指定代码分支，从而保证开发者提交的增量代码被合法、有效的提交到指定代码分支上，保证了合并后的代码的预期功能标准。

进一步地，当校验信息中包括代码提交时间窗口时，则判断当前增量代码的提交时间是否位于所述代码提交时间窗口中，如果位于，则确定针对代码提交时间窗口对应的校验项上增量代码通过验证。

进一步地，当校验信息中包括在预验证阶段对应的增量代码的内容验证信息以及基线版本信息，则根据内容验证信息对增量代码的内容进行验证，如果验证通过，则确定针对增量代码的内容对应的校验项上增量代码通过验证；判断当前代码库中基线版本是否与校验信息中记录的基线版本相同，如果相同，则确定针对基线版本对应的校验项上增量代码通过验证。

进一步地，通过在代码提交时间窗口内解锁指定代码分支，并提交增量代码至指定代码分支，以保证多个开发者向同一代码分支提交增量代码时不会出现冲突。

实施例四

本实施例方法步骤从更具体的实际操作流程的角度出发，基于图1中所示的代码提交逻辑架构，对上述实施例中的预验证阶段，代码提交阶段的执行过程进行具体描述。图7所示，该代码提交方法包括如下步骤：

代码预验证阶段：

1.提交patch。

开发者向调度分发服务器提交一个包含patch的预验证请求。

2.记录patch信息。

调度分发服务器记录本次提交的patch的信息到调度数据库，该信息内容包括：如patch的hash值，以用于后期在代码提交阶段开发者提交patch时，验证该patch是否跟预验证过程中的patch的内容一致。

3.应用patch。

调度分发服务器将patch转发给后台验证集群，以执行集成功能测试。

4.同步测试集代码。

执行测试前，后台验证集群需要根据提交的patch从代码托管服务器同步相应的测试集代码(测试集代码是根据预设的代码质量策略提前编辑的)。同时还要提前同步基线代码，以与提交的patch进行合并。

5.合并代码，执行测试。

通过后台验证集群对patch的功能质量进行预验证。后台验证集群会根据预设的代码质量策略，对本次提交的patch和代码托管服务器中当前的基线代码进行合并、执行测试回归。

其中，这里的基线代码是指代码分支上一个通过了功能验证的代码分支版本commit#。如果有新的增量代码合并进来，并通过了系统级的功能验证，那么合并后的commit#就是新的基线版本。

上述预验证是可以并发验证的，即多个开发者可以并发的针对同一个代码分支提交patch发起预验证过程。

6.返回测试结果。

后台验证集群将本次测试的结果返回至调度分发服务器，如果回归结果是通过的，则证明本次patch满足质量标准，否则，证明本次patch不满足质量标准。

7.记录测试结果、形成patch内容hash、基线版本、代码提交时间窗口(token)。

如果6中测试结果是通过，则调度分发服务器会产生一个带有代码提交时间窗口信息(已加密)的token。Token是一个涵盖了“基线版本信息+patch全文内容hash值+代码提交时间窗口”的encode值。调度分发服务器将本次的patch验证结果以及得到的token值记录在调度数据库里。

8.通知验证结果，返回token。

调度分发服务器向开发者发布预验证结果，并且返回生成的上述token(这里的token可视为校验令牌)。如果测试回归结果失败，通知开发者具体错误的内容，以等待开发者修改patch后，重新提交patch进行预验证。

这里需要说明的是，将token返回给开发者，只是对预验证通过的patch给予一个全局变量，用于唯一标识这个patch，实际上只要这个全局变量能够与上述三个内容：“基线版本信息+patch全文内容hash值+代码提交时间窗口”相对应，那么这个全局变量具体内容并不限定，本方案中，为了节省计算量，将这个全局变量直接设定为就是token，与前述内容中的校验令牌功能是一致。

9.释放验证环境。

如果本次预验证成功，则调度分发服务器通知后台验证集群释放预验证环境，节省资源；如果本次预验证不成功，则调度分发服务器通知后台验证集群不释放预验证环境，保留预验证环境供开发者debug，待过期后清理。

10.设定时间窗口，锁定代码分支。

调度分发服务器通知代码托管服务器暂时闭锁该代码分支，避免其他开发者提交代码造成的冲突和代码质量扰动，闭锁行为在代码提交时间窗口内有效。

代码提交阶段：

提交代码到托管服务器是需要同步机制的，因为不同的patch在被竞相提交的过程中，可能会导致测试系统的功能退化(回归测试通过率下降)，所以提交过程必须要有一个同步的机制。

11.提交patch，非法token。

开发者将预验证通过的patch提交给调度分发服务器，同时提交之前在预验证阶段由调度分发服务器反馈的token。这里的非法不仅是指token本身错误，还包括其对应的验证信息已经不合法了。比如，基线版本和当前代码库中的基线版本已经不同、代码提交窗口时间过期，本次提交的patch与之前预验证阶段提交的patch在内容上不同(通过patch内容的hash值验证patch内容的一致性)。

12.获取patch内容hash、基线版本、时间窗口。

调度分发服务器接收到开发者提交的patch后，根据全局变量token，从调度数据库中获取对应的校验信息，包括如patch内容的hash、基线版本、代码提交时间窗口。

13.验证失败。

调度分发服务器根据验证信息依次对提交的patch进行验证。验证内容包括：patch预验证时所用的基线版本和当前代码分支最新的基线版本是否相同；根据Patch内容计算hash值，patch的内容hash结果是否和调度数据库里的记录的patch的内容hash相同，以确认本次提交的patch和预验证时的patch内容是否一致；验证代码提交时间窗口是否合法。

为了减少验证的工作量，校验顺序依次是：代码提交时间窗口、基线版本、patch内容的hash。由于本次提交的是非法token，所以验证失败。

14.非法提交。

调度分发服务器通知开发者本次代码提交失败，是非法提交。

15.提交patch，合法token。

本步骤与11相似，区别在于所提交的token是合法的。

16.获取patch内容hash、基线版本、时间窗口。

本步骤与12相同。

17.验证成功。

本步骤中的验证过程与13内容相同，由于本次提交的是合法token，所以验证成功。

18.解锁代码分支，上传代码。

如果以上三步的验证都通过，那么调度分发服务器通知代码托管服务器打开代码分支闭锁，允许带有本次已验证过的token的patch提交到代码托管服务器上，代码托管服务器会更新代码基线版本。

19.通知patch成功提交。

调度分发服务器会通知开发者本次代码提交成功。代码提交成功后，通知其他所有开发者继续代码预验证、以及发起代码提交的请求，新一轮的预验证应当应用新的基线版本。

基线版本会被记录在调度数据库中，这个基线版本一旦变更，其他开发者的预验证和提交工作将受到影响，必须重走预验证流程。

20.超过时间窗口，未检测到patch提交，解锁代码分支。

当超过时间窗口规定时间后，调度分发服务器会通知代码托管服务器解锁相应的代码分支，以等待下一次的代码提交过程。

实施例五

如图8所示，为本发明实施例的代码提交装置结构图一，该代码提交装置可设置在图1所示的代码提交逻辑架构中的调度分发服务器中，用于执行如图2所示的方法步骤，其包括：

代码获取模块810，用于获取待向代码库的指定代码分支提交的增量代码；

代码预验证模块820，用于对增量代码进行预验证，预验证包括将当前代码库中的基线代码与增量代码进行合并，并对合并后的代码通过预置测试集代码进行集成功能测试；

代码提交模块830，用于提交预验证通过的增量代码至代码库的指定代码分支。

进一步地，如图9所示，在图8所示的代码提交装置中还可包括：

校验信息生成模块910，用于如果预验证通过，则生成用于提交预验证通过的增量代码至代码库的指定代码分支的校验信息；

预验证结果反馈模块920，用于向本次提交增量代码的开发者反馈预验证结果信息，预验证结果信息中包括在预验证通过后增加的，与校验信息关联的校验令牌。

图9所示代码提交装置可用于执行如图3所示的方法步骤。

进一步地，如图10所示，在图9所示的代码提交装置中还可包括：

时间窗口生成模块101，用于如果预验证通过，则设置代码提交时间窗口；代码提交时间窗口用于在对应时间内锁定指定代码分支，仅允许被分配在代码提交时间窗口内提交的增量代码有权限对指定代码分支进行解锁；

相应的，校验信息中包括用于提交增量代码至代码库的指定代码分支的代码提交时间窗口。

图10所示代码提交装置可用于执行如图4所示的方法步骤。

进一步地，上述校验信息中还可包括：在预验证阶段对应的增量代码的内容验证信息、基线版本信息。

进一步地，上述代码提交装置中还可包括：验证环境释放模块，用于如果预验证通过，则释放预验证环境。

进一步地，如图11所示，在上述图9或图10所示的代码提交装置中，代码提交模块830可包括：

提交请求获取单元111，用于接收预验证通过的增量代码的提交请求，提交请求中携带校验令牌；

代码验证单元112，用于根据与校验令牌关联的校验信息，对增量代码进行验证；

代码提交单元113，用于提交验证通过的增量代码至代码库的指定代码分支。

进一步地，当校验信息中包括用于提交预验证通过的增量代码至代码库的指定代码分支的代码提交时间窗口，则代码验证单元112可用于，判断当前增量代码的提交时间是否位于代码提交时间窗口中，如果位于，则确定针对代码提交时间窗口对应的校验项上增量代码通过验证。

进一步地，当校验信息中包括在预验证阶段对应的增量代码的内容验证信息以及基线版本信息，则代码验证单元112可用于，

根据内容验证信息对增量代码的内容进行验证，如果验证通过，则确定针对增量代码的内容对应的校验项上增量代码通过验证；

判断当前代码库中基线版本是否与校验信息中记录的基线版本相同，如果相同，则确定针对基线版本对应的校验项上增量代码通过验证。

图11所示代码提交装置可用于执行如图5、图6所示的方法步骤。

本发明提供的代码提交装置，在获取待向代码库的指定代码分支提交的增量代码后，先对增量代码进行预验证，该预验证包括将当前代码库中的基线代码与增量代码进行合并，并对合并后的代码通过预置测试集代码进行集成功能测试；然后，提交预验证通过的增量代码至代码库的指定代码分支。本方案中将代码分支提交和集成测试自动化流程进行无缝对接，实现对目标分支代码在可交付功能层面的质量监控和运维自动化，避免代码提交后导致的主干代码集成功能质量不达标的问题，使得主干代码随时处于可交付状态。

进一步地，在对增量代码进行预验证之后，如果预验证通过，则生成用于提交预验证通过的增量代码至代码库的指定代码分支的校验信息；向本次提交增量代码的开发者反馈预验证结果信息，该预验证结果信息中包括在预验证通过后增加的，与校验信息关联的校验令牌。通过在增量代码通过预验证后，生成用于在代码提交阶段对待提交的增量代码进行验证的校验信息，并在预验证结果信息中增加校验令牌，从而为后续代码提交阶段，为提交增量代码至指定代码分支提供便利，并保证正确提交，使得合并后的目标代码的功能达到预期标准。

进一步地，在对增量代码进行预验证之后，如果预验证通过，则设置代码提交时间窗口；该代码提交时间窗口用于在对应时间内锁定指定代码分支，仅允许被分配在代码提交时间窗口内提交的增量代码有权限对指定代码分支进行解锁；相应的，在校验信息中包括用于提交增量代码至代码库的指定代码分支的代码提交时间窗口，从而保证被提交到同一个代码分支上的多个增量代码之间不会发生提交冲突，从而避免造成同一代码分支上的功能冲突。

进一步地，上述校验信息中还包括：在预验证阶段对应的增量代码的内容验证信息、基线版本信息，以对代码提交阶段的增量代码在内容以及所适用的基板版本进行验证，确保预验证阶段和代码提交阶段中目标代码合并结果的一致性。

进一步地，通过接收预验证通过的增量代码的提交请求，提交请求中携带所述校验令牌；并根据与校验令牌关联的校验信息，对增量代码进行验证；提交验证通过的增量代码至代码库的指定代码分支，从而保证开发者提交的增量代码被合法、有效的提交到指定代码分支上，保证了合并后的代码的预期功能标准。

进一步地，当校验信息中包括代码提交时间窗口时，则判断当前增量代码的提交时间是否位于所述代码提交时间窗口中，如果位于，则确定针对代码提交时间窗口对应的校验项上增量代码通过验证。

进一步地，当校验信息中包括在预验证阶段对应的增量代码的内容验证信息以及基线版本信息，则根据内容验证信息对增量代码的内容进行验证，如果验证通过，则确定针对增量代码的内容对应的校验项上增量代码通过验证；判断当前代码库中基线版本是否与校验信息中记录的基线版本相同，如果相同，则确定针对基线版本对应的校验项上增量代码通过验证。

进一步地，通过在代码提交时间窗口内解锁指定代码分支，并提交增量代码至指定代码分支，以保证多个开发者向同一代码分支提交增量代码时不会出现冲突。

实施例六

前面实施例描述了代码提交装置的整体架构，该装置的功能可借助一种电子设备实现完成，如图12所示，其为本发明实施例的电子设备的结构示意图，具体包括：存储器121和处理器122。

存储器121，用于存储程序。

除上述程序之外，存储器121还可被配置为存储其它各种数据以支持在电子设备上的操作。这些数据的示例包括用于在电子设备上操作的任何应用程序或方法的指令，联系人数据，电话簿数据，消息，图片，视频等。

存储器121可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。

处理器122，耦合至存储器121，用于执行存储器121中的程序，所述程序运行时执行如图3至图7中任意一种代码提交方法。

上述的具体处理操作已经在前面实施例中进行了详细说明，在此不再赘述。

进一步，如图12所示，电子设备还可以包括：通信组件123、电源组件124、音频组件125、显示器126等其它组件。图12中仅示意性给出部分组件，并不意味着电子设备只包括图12所示组件。

通信组件123被配置为便于电子设备和其他设备之间有线或无线方式的通信。电子设备可以接入基于通信标准的无线网络，如WiFi，2G或3G，或它们的组合。在一个示例性实施例中，通信组件123经由广播信道接收来自外部广播管理系统的广播信号或广播相关信息。在一个示例性实施例中，通信组件123还包括近场通信(NFC)模块，以促进短程通信。例如，在NFC模块可基于射频识别(RFID)技术，红外数据协会(IrDA)技术，超宽带(UWB)技术，蓝牙(BT)技术和其他技术来实现。

电源组件124，为电子设备的各种组件提供电力。电源组件124可以包括电源管理系统，一个或多个电源，及其他与为电子设备生成、管理和分配电力相关联的组件。

音频组件125被配置为输出和/或输入音频信号。例如，音频组件125包括一个麦克风(MIC)，当电子设备处于操作模式，如呼叫模式、记录模式和语音识别模式时，麦克风被配置为接收外部音频信号。所接收的音频信号可以被进一步存储在存储器121或经由通信组件123发送。在一些实施例中，音频组件125还包括一个扬声器，用于输出音频信号。

显示器126包括屏幕，其屏幕可以包括液晶显示器(LCD)和触摸面板(TP)。如果屏幕包括触摸面板，屏幕可以被实现为触摸屏，以接收来自用户的输入信号。触摸面板包括一个或多个触摸传感器以感测触摸、滑动和触摸面板上的手势。触摸传感器可以不仅感测触摸或滑动动作的边界，而且还检测与触摸或滑动操作相关的持续时间和压力。

本领域普通技术人员可以理解：实现上述各方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成。前述的程序可以存储于一计算机可读取存储介质中。该程序在执行时，执行包括上述各方法实施例的步骤；而前述的存储介质包括：ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。

最后应说明的是：以上各实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述各实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的范围。

Claims (19)

1.一种代码提交方法，包括：

获取待向代码库的指定代码分支提交的增量代码；

对所述增量代码进行预验证，所述预验证包括将当前所述代码库中的基线代码与所述增量代码进行合并，并对合并后的代码通过预置测试集代码进行集成功能测试；

提交预验证通过的增量代码至所述代码库的指定代码分支。

2.根据权利要求1所述的方法，其中，所述对所述增量代码进行预验证之后包括：

如果预验证通过，则生成用于提交预验证通过的所述增量代码至所述代码库的指定代码分支的校验信息；

向本次提交所述增量代码的开发者反馈预验证结果信息，所述预验证结果信息中包括在预验证通过后增加的，与所述校验信息关联的校验令牌。

3.根据权利要求2所述的方法，其中，所述对所述增量代码进行预验证之后包括：

如果预验证通过，则设置代码提交时间窗口；所述代码提交时间窗口用于在对应时间内锁定所述指定代码分支，仅允许被分配在所述代码提交时间窗口内提交的增量代码有权限对所述指定代码分支进行解锁；

所述校验信息中包括所述用于提交所述增量代码至所述代码库的指定代码分支的代码提交时间窗口。

4.根据权利要求3所述的方法，其中，所述校验信息中还包括：在所述预验证阶段对应的所述增量代码的内容验证信息、基线版本信息。

5.根据权利要求1所述的方法，其中，所述对所述增量代码进行预验证之后包括：

如果预验证通过，则释放预验证环境。

6.根据权利要求2-5中任一项所述的方法，其中，所述提交预验证通过的增量代码至所述代码库的指定代码分支包括：

接收预验证通过的增量代码的提交请求，所述提交请求中携带所述校验令牌；

根据与所述校验令牌关联的校验信息，对所述增量代码进行验证；

提交验证通过的增量代码至所述代码库的指定代码分支。

7.根据权利要求6所述的方法，其中，当所述校验信息中包括代码提交时间窗口，则根据所述校验信息对所述增量代码进行验证包括：

判断当前所述增量代码的提交时间是否位于所述代码提交时间窗口中，如果位于，则确定针对所述代码提交时间窗口对应的校验项上所述增量代码通过验证。

8.根据权利要求7所述的方法，其中，当所述校验信息中包括在所述预验证阶段对应的所述增量代码的内容验证信息以及基线版本信息，则根据所述校验信息对所述增量代码进行验证包括：

根据所述内容验证信息对所述增量代码的内容进行验证，如果验证通过，则确定针对所述增量代码的内容对应的校验项上所述增量代码通过验证；

判断当前代码库中基线版本是否与校验信息中记录的基线版本相同，如果相同，则确定针对所述基线版本对应的校验项上所述增量代码通过验证。

9.根据权利要求7或8所述的方法，其中，所述提交验证通过的增量代码至所述代码库的指定代码分支包括：

在所述代码提交时间窗口内解锁所述指定代码分支，并提交所述增量代码至所述指定代码分支。

10.一种代码提交装置，包括：

代码获取模块，用于获取待向代码库的指定代码分支提交的增量代码；

代码预验证模块，用于对所述增量代码进行预验证，所述预验证包括将当前所述代码库中的基线代码与所述增量代码进行合并，并对合并后的代码通过预置测试集代码进行集成功能测试；

代码提交模块，用于提交预验证通过的增量代码至所述代码库的指定代码分支。

11.根据权利要求10所述的装置，其中，所述装置还包括：

校验信息生成模块，用于如果预验证通过，则生成用于提交预验证通过的所述增量代码至所述代码库的指定代码分支的校验信息；

预验证结果反馈模块，用于向本次提交所述增量代码的开发者反馈预验证结果信息，所述预验证结果信息中包括在预验证通过后增加的，与所述校验信息关联的校验令牌。

12.根据权利要求11所述的装置，其中，所述装置还包括：

时间窗口生成模块，用于如果预验证通过，则设置代码提交时间窗口；所述代码提交时间窗口用于在对应时间内锁定所述指定代码分支，仅允许被分配在所述代码提交时间窗口内提交的增量代码有权限对所述指定代码分支进行解锁；

所述校验信息中包括所述用于提交所述增量代码至所述代码库的指定代码分支的代码提交时间窗口。

13.根据权利要求12所述的装置，其中，所述校验信息中还包括：在所述预验证阶段对应的所述增量代码的内容验证信息、基线版本信息。

14.根据权利要求10所述的装置，其中，所述装置还包括：

验证环境释放模块，用于如果预验证通过，则释放预验证环境。

15.根据权利要求11-14任一项所述的装置，其中，所述代码提交模块包括：

提交请求获取单元，用于接收预验证通过的增量代码的提交请求，所述提交请求中携带所述校验令牌；

代码验证单元，用于根据与所述校验令牌关联的校验信息，对所述增量代码进行验证；

代码提交单元，用于提交验证通过的增量代码至所述代码库的指定代码分支。

16.根据权利要求15所述的装置，其中，当所述校验信息中包括用于提交预验证通过的增量代码至所述代码库的指定代码分支的代码提交时间窗口，则所述代码验证单元用于，

判断当前所述增量代码的提交时间是否位于所述代码提交时间窗口中，如果位于，则确定针对所述代码提交时间窗口对应的校验项上所述增量代码通过验证。

17.根据权利要求16所述的装置，其中，当所述校验信息中包括在所述预验证阶段对应的所述增量代码的内容验证信息以及基线版本信息，则所述代码验证单元用于，

根据所述内容验证信息对所述增量代码的内容进行验证，如果验证通过，则确定针对所述增量代码的内容对应的校验项上所述增量代码通过验证；

判断当前代码库中基线版本是否与校验信息中记录的基线版本相同，如果相同，则确定针对所述基线版本对应的校验项上所述增量代码通过验证。

18.根据权利要求16或17所述的装置，其中，

所述代码提交单元，用于在所述代码提交时间窗口内解锁所述指定代码分支，并提交所述增量代码至所述指定代码分支。

19.一种电子设备，包括：

存储器，用于存储程序；

处理器，耦合至所述存储器，用于执行所述程序，所述程序运行时执行权利要求1-9中任意一项权利要求所述的代码提交方法。

Images