CN109032625A - 一种软件持续集成方法及装置 - Google Patents

Abstract

本发明提供了一种自动化持续集成方法及装置，包括：接收开发人员提交的源码；将所述开发人员提交的源码合并到预设的主干代码中；利用预先设置的Jenkins程序编译合并后的所述主干代码，形成待运行代码；利用所述Jenkins程序对所述待运行代码进行打包形成待运行服务；测试所述待运行服务，并获得测试结果；当所述测试结果为通过测试时，发布所述待运行服务。本方案能够缩短持续集成的时间。

Description

一种软件持续集成方法及装置

技术领域

本发明涉及软件集成技术领域，特别涉及一种软件持续集成方法及装置。

背景技术

随着软件开发复杂度的不断提高，团队开发成员间如何更好地协同工作以确保软件开发的质量已经慢慢成为开发过程中不可回避的问题，如何能在不断变化的需求中快速适应和保证软件的质量也显得尤其的重要。

持续集成正是针对这一类问题的一种软件开发实践，它倡导团队开发成员必须经常集成他们的工作，甚至每天都可能发生多次集成，以尽快地发现集成错误，让团队能够更快的开发内聚的软件。

但是，目前的持续集成中的构建过程主要通过人工手动编排处理，这会增加构建的时间，从而延长了持续集成的时间。

发明内容

本发明实施例提供了一种软件持续集成方法及装置，能够缩短持续集成的时间。

第一方面，本发明实施例提供了一种自动化持续集成方法，包括：

接收开发人员提交的源码；

将所述开发人员提交的源码合并到预设的主干代码中；

利用预先设置的Jenkins程序编译合并后的所述主干代码，形成待运行代码；

利用所述Jenkins程序对所述待运行代码进行打包形成待运行服务；

测试所述待运行服务，并获得测试结果；

当所述测试结果为通过测试时，发布所述待运行服务。

优选地，

在所述接收开发人员提交的源码之后，在所述将所述开发人员提交的源码合并到预设的主干代码中之前，进一步包括：

利用预先设置的初始脚本对所述开发人员提交的源码进行初始检测，其中，所述初始检测，包括：格式检测、语法检测和逻辑复杂度检测中的任意一个或多个；

当所述开发人员提交的源码的所述初始检测验证通过时，执行所述将所述开发人员提交的源码合并到预设的主干代码中。

优选地，

当所述待运行服务为程序包时，

所述利用所述Jenkins程序对所述待运行代码进行打包形成待运行服务，包括：

利用所述Jenkins程序，调用预设的程序包服务将所述待运行代码打包成程序包；

在所述测试所述待运行服务，并获得测试结果之前，进一步包括：

利用所述Jenkins程序将所述程序包发布到预先搭建的测试环境中；

所述测试所述待运行服务，并获得测试结果，包括：

调用预设的程序包测试脚本对所述测试环境中的所述程序包进行功能测试，并获得所述程序包的测试结果；

所述发布所述待运行服务，包括：

将所述程序包发布到预先搭建的生产环境中。

优选地，

当所述待运行服务为镜像时，

所述利用所述Jenkins程序对所述待运行代码进行打包形成待运行服务，包括：

利用所述Jenkins程序，调用预设的Docker服务将所述待运行代码打包成镜像；

在所述测试所述待运行服务，并获得测试结果之前，进一步包括：

在所述测试环境中设置测试容器；

利用所述Jenkins程序将所述镜像存储到所述测试容器中；

所述测试所述待运行服务，并获得测试结果，包括：

调用预设的镜像测试脚本对存储所述镜像后的所述测试容器进行功能测试，并获得所述镜像的测试结果；

在所述发布所述待运行服务之前，进一步包括：

在所述生产环境中设置待运行容器；

所述发布所述待运行服务，包括：

将所述镜像存储到所述待运行容器中。

优选地，

所述利用预先设置的Jenkins程序编译合并后的所述主干代码，形成待运行代码，包括：

利用预先设置的Jenkins程序将合并后的所述主干代码转换为二进制的待运行代码。

优选地，

在所述获得测试结果之后，进一步包括：

当所述测试结果为测试未通过时，生成测试报告；

将所述测试报告反馈给所述开发人员。

第二方面，本发明实施例提供了一种自动化持续集成装置，包括：

管理单元，用于接收开发人员提交的源码；将所述开发人员提交的源码合并到预设的主干代码中；

构建单元，用于利用预先设置的Jenkins程序编译被所述管理单元加入所述源码后的所述主干代码，形成待运行代码；利用所述Jenkins程序对所述待运行代码进行打包形成待运行服务；

测试单元，用于测试所述构建单元打包形成的所述待运行服务，并获得测试结果；当所述测试结果为通过测试时，发布所述待运行服务。

优选地，

所述测试单元，进一步用于利用预先设置的初始脚本对所述管理单元接收的所述开发人员提交的源码进行初始检测，其中，所述初始检测，包括：格式检测、语法检测和逻辑复杂度检测中的任意一个或多个；

所述管理单元，进一步用于当所述测试单元确定所述开发人员提交的源码的所述初始检测验证通过时，执行所述将所述开发人员提交的源码合并到预设的主干代码中。

优选地，

当所述待运行服务为程序包时，

所述构建单元，用于利用所述Jenkins程序，调用预设的程序包服务将所述待运行代码打包成程序包；利用所述Jenkins程序将所述程序包发布到预先搭建的测试环境中；

所述测试单元，用于调用预设的程序包测试脚本对所述测试环境中的所述程序包进行功能测试，并获得所述程序包的测试结果；将所述程序包发布到预先搭建的生产环境中。

优选地，进一步包括：设置单元；

当所述待运行服务为镜像时，

所述设置单元，用于在所述测试环境中设置测试容器；在所述生产环境中设置待运行容器；

所述构建单元，用于利用所述Jenkins程序，调用预设的Docker服务将所述待运行代码打包成镜像；利用所述Jenkins程序将所述镜像存储到所述设置单元设置的所述测试容器中；

所述测试单元，用于调用预设的镜像测试脚本对被所述构建单元存储所述镜像后的所述测试容器进行功能测试，并获得所述镜像的测试结果；将所述镜像存储到所述设置单元设置的所述待运行容器中。

优选地，

所述构建单元，用于利用预先设置的Jenkins程序将合并后的所述主干代码转换为二进制的待运行代码。

优选地，

所述测试单元，进一步用于当所述测试结果为测试未通过时，生成测试报告；将所述测试报告反馈给所述开发人员。

在本发明实施例中，在接收到开发人员提交的源码后，需要先将源码合并到主干代码中，再利用Jenkins程序对合并后的主干代码进行编译、打包，形成测试时可识别、可运行的待运行服务，再对形成的待运行服务进行测试，即可确定开发人员提交的源码是否存在缺陷，当源码不存在缺陷使得待运行服务通过测试时，需要发布待运行服务，以完成持续集成过程。综上可见，在持续集成过程中，利用Jenkins程序对代码进行自动化构建，可以缩短人工手动构建的施加，从而实现缩短持续集成时间的目的。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本发明一实施例提供的一种自动化持续集成方法的流程图；

图2是本发明一实施例提供的另一种自动化持续集成方法的流程图；

图3是本发明一实施例提供的一种自动化持续集成装置的结构示意图；

图4是本发明一实施例提供的另一种自动化持续集成装置的结构示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例，基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本发明保护的范围。

如图1所示，本发明实施例提供了一种自动化持续集成方法，包括：

步骤101：接收开发人员提交的源码；

步骤102：将所述开发人员提交的源码合并到预设的主干代码中；

步骤103：利用预先设置的Jenkins程序编译合并后的所述主干代码，形成待运行代码；

步骤104：利用所述Jenkins程序对所述待运行代码进行打包形成待运行服务；

步骤105：测试所述待运行服务，并获得测试结果；

步骤106：当所述测试结果为通过测试时，发布所述待运行服务。

在本发明实施例中，在接收到开发人员提交的源码后，需要先将源码合并到主干代码中，再利用Jenkins程序对合并后的主干代码进行编译、打包，形成测试时可识别、可运行的待运行服务，再对形成的待运行服务进行测试，即可确定开发人员提交的源码是否存在缺陷，当源码不存在缺陷使得待运行服务通过测试时，需要发布待运行服务，以完成持续集成过程。综上可见，在持续集成过程中，利用Jenkins程序对代码进行自动化构建，可以缩短人工手动构建的施加，从而实现缩短持续集成时间的目的。

在本发明一实施例中，在所述接收开发人员提交的源码之后，在所述将所述开发人员提交的源码合并到预设的主干代码中之前，进一步包括：

利用预先设置的初始脚本对所述开发人员提交的源码进行初始检测，其中，所述初始检测，包括：格式检测、语法检测和逻辑复杂度检测中的任意一个或多个；

当所述开发人员提交的源码的所述初始检测验证通过时，执行所述将所述开发人员提交的源码合并到预设的主干代码中。

在本发明实施例中，在将开发人员提交的源码合并到主干代码之前，需要先对源码进行初始检测，以确定源码的质量。例如，确定源码的格式和语法是否正确，逻辑复杂度是否过高，不利于理解、测试和维护。

在本发明一实施例中，当所述待运行服务为程序包时，

所述利用所述Jenkins程序对所述待运行代码进行打包形成待运行服务，包括：

利用所述Jenkins程序，调用预设的程序包服务将所述待运行代码打包成程序包；

在所述测试所述待运行服务，并获得测试结果之前，进一步包括：

利用所述Jenkins程序将所述程序包发布到预先搭建的测试环境中；

所述测试所述待运行服务，并获得测试结果，包括：

调用预设的程序包测试脚本对所述测试环境中的所述程序包进行功能测试，并获得所述程序包的测试结果；

所述发布所述待运行服务，包括：

将所述程序包发布到预先搭建的生产环境中。

在本发明实施例中，利用Jenkins程序对待运行代码进行构建打包时，可以将待运行代码打包成程序包，将程序包发布到预先搭建的测试环境中即可进行功能测试，以确定开发人员提交的源码是否存在缺陷，是否与主干代码存在冲突。在确定程序包通过测试时，需要在预先搭建的生产环境中搭建程序包运行时需要的运行环境，再将程序包发布到搭建的运行环境中即可运行该程序包。

在本发明一实施例中，当所述待运行服务为镜像时，

所述利用所述Jenkins程序对所述待运行代码进行打包形成待运行服务，包括：

利用所述Jenkins程序，调用预设的Docker服务将所述待运行代码打包成镜像；

在所述测试所述待运行服务，并获得测试结果之前，进一步包括：

在所述测试环境中设置测试容器；

利用所述Jenkins程序将所述镜像存储到所述测试容器中；

所述测试所述待运行服务，并获得测试结果，包括：

调用预设的镜像测试脚本对存储所述镜像后的所述测试容器进行功能测试，并获得所述镜像的测试结果；

在所述发布所述待运行服务之前，进一步包括：

在所述生产环境中设置待运行容器；

所述发布所述待运行服务，包括：

将所述镜像存储到所述待运行容器中。

在本发明实施例中，利用Jenkins程序在打包待运行代码时，还可以通过调用Docker服务将待运行代码打包成镜像，不仅可以提高代码构建的效率，可以避免因程序语言格式不同，需要将待运行代码打包形成特定格式的待运行服务。在对加入镜像后的测试容器进行测试时，需要将加入镜像后的测试容器存储到测试环境中设置的测试容器中，通过对测试容器进行测试，即可确定开发人员提交的源码是否存在缺陷，是否与主干代码存在冲突。并在确定测试容器通过测试时，可以将镜像存储到生产环境中的待运行容器中运行。

在本发明一实施例中，所述利用预先设置的Jenkins程序编译合并后的所述主干代码，形成待运行代码，包括：

利用预先设置的Jenkins程序将合并后的所述主干代码转换为二进制的待运行代码。

在本发明实施例中，利用Jenkins程序将合并后的主干代码转换为二进制的待运行代码，以便于计算机可以识别二进制的待运行代码完成测试，同时还可以缩短构建编译的时间，进而缩短持续集成的时间。

在本发明一实施例中，在所述获得测试结果之后，进一步包括：

当所述测试结果为测试未通过时，生成测试报告；

将所述测试报告反馈给所述开发人员。

在本发明实施例中，当待运行服务的测试结果为测试未通过时，则需要生成测试报告，测试报告可以包括测试过程、测试结果、源码中存在的问题和缺陷的进行分析，将测试报告反馈给开发人员，开发人员即可根据测试报告修改源码，再提交修改后的源码，进行构建、测试，以形成闭环的流程。

为了更加清楚的说明本发明的技术方案及优点，下面以待运行服务为镜像为例，对本发明提供的一种自动化持续集成方法进行详细说明，如图2所示，具体可以包括以下步骤：

步骤201，接收开发人员提交的源码。

具体地，通过接收开发人员提交的源码，可以对源码进行测试，确定开发人员提交的源码是否存在缺陷，是否与主干代码存在冲突。

举例来说，在接收到开发人员提交的源码时，可以将其存储到内部的源码库中。

步骤202，利用预先设置的初始脚本对开发人员提交的源码进行初始检测，其中，初始检测，包括：格式检测、语法检测和逻辑复杂度检测中的任意一个或多个。

具体地，通过持续集成过程中控制流程的流水线在监测到开发人员提交的源码后，需要先对源码的格式、语法，以及逻辑复杂度进行检测，以使确定源码格式和语法是否正确，逻辑复杂度是否过于复杂，难以理解、测试和维护等问题，确定源码的质量。

步骤203，当开发人员提交的源码的初始检测验证通过时，将开发人员提交的源码合并到预设的主干代码中。

具体地，在确定开发人员提交的源码的格式、语法以及逻辑复杂度验证通过时，可以将源码合并到主干代码中，以使对合并后的主干代码进行功能测试。

举例来说，在确定开发人员提交的源码的格式、语法、逻辑复杂度均通过验证时，可以将源码库中的源码与源码库中预设的主干代码进行合并。

步骤204，利用预先设置的Jenkins程序将合并后的主干代码转换为二进制的待运行代码。

具体地，通过持续集成过程中控制流程的流水线在监测到源码与主干代码合并后，可以触发Jenkins程序，通过触发Jenkins程序对合并后的主干代码进行构建，即将合并后的主干代码转换为二进制的待运行代码，以使计算机可以识别待运行代码。

步骤205，利用Jenkins程序，调用预设的Docker服务将待运行代码打包成镜像。

具体地，在将合并后的主干代码转换为二进制的待运行代码后，即可进行构建打包处理，利用Jenkins程序调用Docker服务将待运行代码打包成镜像，以使将待运行代码打包成可运行的程序。

需要说明的是，在对待运行代码打包时，还可以将待运行代码打包为程序包，通过测试打包的程序包，确定开发人员提交的源码是否存在缺陷。

步骤206，利用Jenkins程序将镜像存储到预先搭建的测试环境中设置的测试容器内。

具体地，在构建打包完成后，需要将镜像发布到预先搭建的测试环境中预先设置的测试容器内，以使在测试环境下通过测试容器对镜像进行功能测试。

举例来说，在预先搭建的测试环境中设置测试容器，利用Jenkins程序将待运行代码打包成镜像后，需要将镜像发布到测试环境中，即将镜像存储到设置的测试容器中。

步骤207，调用预设的镜像测试脚本对存储镜像后的测试容器进行功能测试，并获得镜像的测试结果。

具体地，在测试镜像时，可以对存储镜像后的测试容器进行功能测试，以避免因配置问题导致镜像的测试失败。

步骤208，当测试结果为通过测试时，将镜像存储到预先搭建的生产环境中设置的待运行容器中。

具体地，当存储镜像后的测试容器通过测试时，可将镜像发布到生产环境中的待运行容器中，以通过待运行容器运行该镜像。

当存储镜像后的测试容器未通过功能测试时，说明源码中可能存在bug，需要生成对应的测试报告，将测试报告反馈给开发人员，以使开发人员根据测试报告对提交的源码进行修改，源码修改后可以重新提交，触发新一轮的构件，形成闭环开发、测试流程。

综上可见，基于在持续集成阶段困扰开发人员的问题，通过构建持续集成过程中控制流程的流水线，可以实现接收开发人员提交的源码，再对源码进行格式、语法、逻辑复杂度进行检测，利用Jenkins程序对合并后的主干代码进行自动编译、打包形成待运行服务，再根据不同的功能将待运行服务发布到不同的环境中，通过对发布的待运行服务进行测试，并对测试数据进行反馈，开发人员可以根据反馈的数据进行源码修改，重新提交源码，触发新一轮的式、语法、逻辑复杂度检测，以及构建，形成闭环的流程。而在构建过程中，通过Jenkins程序自动完成编译、打包处理，可以缩短开发人员手动构建的时间，缩短软件持续集成时间，缩短软件研发周期，提高研发效率。并且还可以减少构建过程中人为参与引发的失误，以及降低人工构建的人力成本。

如图3所示，本发明实施例提供了一种自动化持续集成装置，包括：

管理单元301，用于接收开发人员提交的源码；将所述开发人员提交的源码合并到预设的主干代码中；

构建单元302，用于利用预先设置的Jenkins程序编译被所述管理单元301加入所述源码后的所述主干代码，形成待运行代码；利用所述Jenkins程序对所述待运行代码进行打包形成待运行服务；

测试单元303，用于测试所述构建单元302打包形成的所述待运行服务，并获得测试结果；当所述测试结果为通过测试时，发布所述待运行服务。

在本发明实施例中，管理单元在接收到开发人员提交的源码后，需要先将源码合并到主干代码中，构建单元再利用Jenkins程序对管理单元合并后的主干代码进行编译、打包，形成测试时可识别、可运行的待运行服务，测试单元再对构建单元形成的待运行服务进行测试，即可确定开发人员提交的源码是否存在缺陷，当源码不存在缺陷使得待运行服务通过测试时，需要发布待运行服务，以完成持续集成过程。综上可见，在持续集成过程中，利用Jenkins程序对代码进行自动化构建，可以缩短人工手动构建的施加，从而实现缩短持续集成时间的目的。

在本发明一实施例中，所述测试单元，进一步用于利用预先设置的初始脚本对所述管理单元接收的所述开发人员提交的源码进行初始检测，其中，所述初始检测，包括：格式检测、语法检测和逻辑复杂度检测中的任意一个或多个；

所述管理单元，进一步用于当所述测试单元确定所述开发人员提交的源码的所述初始检测验证通过时，执行所述将所述开发人员提交的源码合并到预设的主干代码中。

在本发明一实施例中，当所述待运行服务为程序包时，

所述构建单元，用于利用所述Jenkins程序，调用预设的程序包服务将所述待运行代码打包成程序包；利用所述Jenkins程序将所述程序包发布到预先搭建的测试环境中；

所述测试单元，用于调用预设的程序包测试脚本对所述测试环境中的所述程序包进行功能测试，并获得所述程序包的测试结果；将所述程序包发布到预先搭建的生产环境中。

基于图3所示的一种自动化持续集成装置，如图4所示，进一步包括：设置单元401；

当所述待运行服务为镜像时，

所述设置单元401，用于在所述测试环境中设置测试容器；在所述生产环境中设置待运行容器；

所述构建单元302，用于利用所述Jenkins程序，调用预设的Docker服务将所述待运行代码打包成镜像；利用所述Jenkins程序将所述镜像存储到所述设置单元401设置的所述测试容器中；

所述测试单元303，用于调用预设的镜像测试脚本对被所述构建单元302存储所述镜像后的所述测试容器进行功能测试，并获得所述镜像的测试结果；将所述镜像存储到所述设置单元设置的所述待运行容器中。

在本发明一实施例中，所述构建单元，用于利用预先设置的Jenkins程序将合并后的所述主干代码转换为二进制的待运行代码。

在本发明一实施例中，所述测试单元，进一步用于当所述测试结果为测试未通过时，生成测试报告；将所述测试报告反馈给所述开发人员。

本发明各个实施例至少具有如下有益效果：

1、在本发明一实施例中，在接收到开发人员提交的源码后，需要先将源码合并到主干代码中，再利用Jenkins程序对合并后的主干代码进行编译、打包，形成测试时可识别、可运行的待运行服务，再对形成的待运行服务进行测试，即可确定开发人员提交的源码是否存在缺陷，当源码不存在缺陷使得待运行服务通过测试时，需要发布待运行服务，以完成持续集成过程。综上可见，在持续集成过程中，利用Jenkins程序对代码进行自动化构建，可以缩短人工手动构建的施加，从而实现缩短持续集成时间的目的。

2、在本发明一实施例中，在将开发人员提交的源码合并到主干代码之前，需要先对源码进行初始检测，以确定源码的质量。例如，确定源码的格式和语法是否正确，逻辑复杂度是否过高，不利于理解、测试和维护。

3、在本发明一实施例中，利用Jenkins程序对待运行代码进行构建打包时，可以将待运行代码打包成程序包，将程序包发布到预先搭建的测试环境中即可进行功能测试，以确定开发人员提交的源码是否存在缺陷，是否与主干代码存在冲突。在确定程序包通过测试时，需要在预先搭建的生产环境中搭建程序包运行时需要的运行环境，再将程序包发布到搭建的运行环境中即可运行该程序包。

4、在本发明一实施例中，利用Jenkins程序在打包待运行代码时，还可以通过调用Docker服务将待运行代码打包成镜像，不仅可以提高代码构建的效率，可以避免因程序语言格式不同，需要将待运行代码打包形成特定格式的待运行服务。在对加入镜像后的测试容器进行测试时，需要将加入镜像后的测试容器存储到测试环境中设置的测试容器中，通过对测试容器进行测试，即可确定开发人员提交的源码是否存在缺陷，是否与主干代码存在冲突。并在确定测试容器通过测试时，可以将镜像存储到生产环境中的待运行容器中运行。

5、在本发明一实施例中，当待运行服务的测试结果为测试未通过时，则需要生成测试报告，测试报告可以包括测试过程、测试结果、源码中存在的问题和缺陷的进行分析，将测试报告反馈给开发人员，开发人员即可根据测试报告修改源码，再提交修改后的源码，进行构建、测试，以形成闭环的流程。

需要说明的是，在本文中，诸如第一和第二之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个······”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同因素。

最后需要说明的是：以上所述仅为本发明的较佳实施例，仅用于说明本发明的技术方案，并非用于限定本发明的保护范围。凡在本发明的精神和原则之内所做的任何修改、等同替换、改进等，均包含在本发明的保护范围内。

Claims (10)

1.一种自动化持续集成方法，其特征在于，包括：

接收开发人员提交的源码；

将所述开发人员提交的源码合并到预设的主干代码中；

利用预先设置的Jenkins程序编译合并后的所述主干代码，形成待运行代码；

利用所述Jenkins程序对所述待运行代码进行打包形成待运行服务；

测试所述待运行服务，并获得测试结果；

当所述测试结果为通过测试时，发布所述待运行服务。

2.根据权利要求1所述的方法，其特征在于，

在所述接收开发人员提交的源码之后，在所述将所述开发人员提交的源码合并到预设的主干代码中之前，进一步包括：

利用预先设置的初始脚本对所述开发人员提交的源码进行初始检测，其中，所述初始检测，包括：格式检测、语法检测和逻辑复杂度检测中的任意一个或多个；

当所述开发人员提交的源码的所述初始检测验证通过时，执行所述将所述开发人员提交的源码合并到预设的主干代码中。

3.根据权利要求1所述的方法，其特征在于，

当所述待运行服务为程序包时，

所述利用所述Jenkins程序对所述待运行代码进行打包形成待运行服务，包括：

利用所述Jenkins程序，调用预设的程序包服务将所述待运行代码打包成程序包；

在所述测试所述待运行服务，并获得测试结果之前，进一步包括：

利用所述Jenkins程序将所述程序包发布到预先搭建的测试环境中；

所述测试所述待运行服务，并获得测试结果，包括：

调用预设的程序包测试脚本对所述测试环境中的所述程序包进行功能测试，并获得所述程序包的测试结果；

所述发布所述待运行服务，包括：

将所述程序包发布到预先搭建的生产环境中。

4.根据权利要求3所述的方法，其特征在于，

当所述待运行服务为镜像时，

所述利用所述Jenkins程序对所述待运行代码进行打包形成待运行服务，包括：

利用所述Jenkins程序，调用预设的Docker服务将所述待运行代码打包成镜像；

在所述测试所述待运行服务，并获得测试结果之前，进一步包括：

在所述测试环境中设置测试容器；

利用所述Jenkins程序将所述镜像存储到所述测试容器中；

所述测试所述待运行服务，并获得测试结果，包括：

调用预设的镜像测试脚本对存储所述镜像后的所述测试容器进行功能测试，并获得所述镜像的测试结果；

在所述发布所述待运行服务之前，进一步包括：

在所述生产环境中设置待运行容器；

所述发布所述待运行服务，包括：

将所述镜像存储到所述待运行容器中。

5.根据权利要求1至4中任一所述的方法，其特征在于，

所述利用预先设置的Jenkins程序编译合并后的所述主干代码，形成待运行代码，包括：

利用预先设置的Jenkins程序将合并后的所述主干代码转换为二进制的待运行代码；

和/或，

在所述获得测试结果之后，进一步包括：

当所述测试结果为测试未通过时，生成测试报告；

将所述测试报告反馈给所述开发人员。

6.一种自动化持续集成装置，其特征在于，包括：

管理单元，用于接收开发人员提交的源码；将所述开发人员提交的源码合并到预设的主干代码中；

构建单元，用于利用预先设置的Jenkins程序编译被所述管理单元加入所述源码后的所述主干代码，形成待运行代码；利用所述Jenkins程序对所述待运行代码进行打包形成待运行服务；

测试单元，用于测试所述构建单元打包形成的所述待运行服务，并获得测试结果；当所述测试结果为通过测试时，发布所述待运行服务。

7.根据权利要求6所述的装置，其特征在于，

所述测试单元，进一步用于利用预先设置的初始脚本对所述管理单元接收的所述开发人员提交的源码进行初始检测，其中，所述初始检测，包括：格式检测、语法检测和逻辑复杂度检测中的任意一个或多个；

所述管理单元，进一步用于当所述测试单元确定所述开发人员提交的源码的所述初始检测验证通过时，执行所述将所述开发人员提交的源码合并到预设的主干代码中。

8.根据权利要求6所述的装置，其特征在于，

当所述待运行服务为程序包时，

所述构建单元，用于利用所述Jenkins程序，调用预设的程序包服务将所述待运行代码打包成程序包；利用所述Jenkins程序将所述程序包发布到预先搭建的测试环境中；

所述测试单元，用于调用预设的程序包测试脚本对所述测试环境中的所述程序包进行功能测试，并获得所述程序包的测试结果；将所述程序包发布到预先搭建的生产环境中。

9.根据权利要求8所述的装置，其特征在于，进一步包括：设置单元；

当所述待运行服务为镜像时，

所述设置单元，用于在所述测试环境中设置测试容器；在所述生产环境中设置待运行容器；

所述构建单元，用于利用所述Jenkins程序，调用预设的Docker服务将所述待运行代码打包成镜像；利用所述Jenkins程序将所述镜像存储到所述设置单元设置的所述测试容器中；

所述测试单元，用于调用预设的镜像测试脚本对被所述构建单元存储所述镜像后的所述测试容器进行功能测试，并获得所述镜像的测试结果；将所述镜像存储到所述设置单元设置的所述待运行容器中。

10.根据权利要求6至9中任一所述的装置，其特征在于，

所述构建单元，用于利用预先设置的Jenkins程序将合并后的所述主干代码转换为二进制的待运行代码；

和/或，

所述测试单元，进一步用于当所述测试结果为测试未通过时，生成测试报告；将所述测试报告反馈给所述开发人员。