CN106897223A - 一种基于持续集成的软件包交付方法及装置 - Google Patents

Abstract

本发明实施例公开了一种基于持续集成的软件包交付方法，实时将开发人员提交的审查成功的代码发送至代码库，当检测当满足预设条件时，将代码库中不同的代码进行组合构建软件包，对该软件包进行集成测试，并将构建的软件包发送至软件库；然后将软件库中的通过集成测试的若干个软件包构建为ISO包，通过PXE将该ISO包进行装机，对其进行***测试，最后将通过***测试的ISO包进行交付。实现了全自动化的持续集成，有效的缩短了研发周期，提高了软件包交付的效率，节省了大量的人力、财力以及物力，具有好的社会经济效率。此外，本发明实施例还提供了相应的实现装置，进一步使得所述方法更具有实用性，所述装置具有相应的优点。

Description

一种基于持续集成的软件包交付方法及装置

技术领域

本发明实施例涉及软件开发技术领域，特别是涉及一种基于持续集成的软件包交付方法及装置。

背景技术

随着计算机技术的飞速发展，软件开发技术也得到了相应的发展。软件开发是根据用户要求建造出软件***或***中的软件部分的过程，包括需求捕捉、需求分析、设计、实现和测试，通常通过某种程序设计语言(例如C语言、JAVA语言)来实现。软件开发过程可为设计软件的功能和实现的算法、软件的总体结构设计和模块设计、编程和调试、程序联调和测试以及编写、提交程序。

现有的软件在研发之前，一般根据需求将整个软件开发划分为多个模块，各模块研发完成后，将各个模块通过接口进行连接，以使各模块间进行通信。尽快这种开发模式实现了各模块间的低耦合，但是在该模式中，只有在所有的代码都开发完成之后然可集成到一起进行测试以及进行bug收敛。

随着软件技术的发展，软件规模的扩大，架构和技术路线的复杂化，这种瀑布式的开发方式的弊端越来越明显，例如早期的bug往往到最后集成的时候才会被发现，从而导致修复bug变得复杂甚至牵扯到底层架构调整，严重时会导致整个软件的研发失败，重新进行研发，进而导致整个软件研发周期增长，浪费了大量的人力以及财力。因此，如何有效的缩短软件的研发周期，提高软件包交付效率，是本领域技术人员亟待解决的问题。

发明内容

本发明实施例的目的是提供一种基于持续集成的软件包交付方法及装置，有效的缩短了软件研发周期，提高了软件包的交付效率。

为解决上述技术问题，本发明实施例提供以下技术方案：

本发明实施例一方面提供了一种基于持续集成的软件包交付方法，包括：

从代码审查平台获取审查成功的代码，并将其发送至代码库；

当满足预设条件时，在所述代码库中选取不同的代码构建预设格式的软件包，将所述软件包发送至项目软件库，并在用户搭建的测试环境中，对所述软件包进行集成测试；

在所述项目软件库中选取通过集成测试的软件包构建ISO包，通过PXE服务器将所述ISO包安装在物理机上，向所述物理机发送运行测试脚本的指令，以对所述ISO包进行***测试；

将通过***测试的ISO包交付所述用户。

可选的，所述在所述项目软件库中选取通过集成测试的软件包构建ISO包包括：

检测持续集成***的负载数目；

当检测到所述持续集成***的负载数目不大于预设阈值时，在所述项目软件库中选取通过集成测试的软件包构建ISO包。

可选的，所述在所述项目软件库中选取通过集成测试的软件包构建ISO包包括：

在预设时间从所述项目软件库中选取通过集成测试的软件包，构建ISO包。

可选的，述预设条件为：

检测到代码进入所述代码库或当前时间为预设时间。

可选的，所述通过PXE服务器将所述ISO包安装在物理机上包括：

获取所述用户为所述PXE服务器配置的文件信息；

根据所述文件信息对DHCP、TFTP以及Kickstart进行配置，并将各自的配置文件发送至相应的服务器中；

所述PXE服务器将所述ISO包，经过所述TFTP服务器下载至所述物理机中；

利用所述Kickstart服务器将所述ISO包安装至所述物理机。

可选的，所述将其发送至代码库包括：

判断当前代码是否与所述代码库中的代码相同；

当判定所述当前代码与所述代码库中的代码不相同时，将所述代码发送至所述代码库。

可选的，所述从代码审查平台获取审查成功的代码，并将其发送至代码库包括：

获取用户上传至所述代码审查平台的代码；

当接收到所述用户对所述代码审阅通过的指令后，对所述代码进行代码格式检查、编译检查以及在所述用户搭建的测试环境中，对所代码进行单元测试；

将经过代码格式检查、编译检查以及单元测试的代码发送至代码库。

本发明实施例另一方面提供了一种基于持续集成的软件包交付装置，包括：

代码入库模块，用于从代码审查平台获取审查成功的代码，并将其发送至代码库；

集成测试模块，用于当满足预设条件时，在所述代码库中选取不同的代码构建预设格式的软件包，将所述软件包发送至项目软件库，并在用户搭建的测试环境中，对所述软件包进行集成测试；

***测试模块，用于在所述项目软件库中选取通过集成测试的软件包构建ISO包，通过PXE服务器将所述ISO包安装在物理机上，向所述物理机发送运行测试脚本的指令，以对所述ISO包进行***测试；

交付模块，用于将通过***测试的ISO包交付所述用户。

可选的，所述***测试模块包括：

监控单元，用于检测持续集成***的负载数目；

构建单元，用于当检测到所述持续集成***的负载数目不大于预设阈值时，在所述项目软件库中选取通过集成测试的软件包构建ISO包。

可选的，所述代码入库模块还包括：

判断单元，用于判断当前代码是否与所述代码库中的代码相同；当判定所述当前代码与所述代码库中的代码不相同时，将所述代码发送至所述代码库。

本发明实施例提供了一种基于持续集成的软件包交付方法，实时将开发人员提交的审查成功的代码发送至代码库，当检测当满足预设条件时，将代码库中不同的代码进行组合构建软件包，对该软件包进行集成测试，并将构建的软件包发送至软件库；然后将软件库中的通过集成测试的若干个软件包构建为ISO包，通过PXE将该ISO包进行装机，对其进行***测试，最后将通过***测试的ISO包进行交付。

在本申请技术方案中，从单元测试到集成测试再到装机进行***测试，实现了全自动化的持续集成，不仅提高了代码的质量与业务逻辑的准确性，有效的缩短了研发周期，提高了软件包交付的效率，从而提高了软件开发的效率；而且有效的减少了人力、财力以及物力的投入，具有好的社会经济效率。

此外，本发明实施例还针对基于持续集成的软件包交付方法提供了相应的实现装置，进一步使得所述方法更具有实用性，所述装置具有相应的优点。

附图说明

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

图1为本发明实施例提供的一种基于持续集成的软件包交付方法的流程示意图；

图2为本发明实施例提供的PXE装机流程示意图；

图3为本发明实施例提供的PXE架构结构示意图；

图4为本发明实施例提供的另一种基于持续集成的软件包交付方法的流程示意图；

图5为本发明实施例提供的持续集成硬件结构示意图；

图6为本发明实施例提供的基于持续集成的软件包交付装置的一种实施方式结构图。

具体实施方式

为了使本技术领域的人员更好地理解本发明方案，下面结合附图和具体实施方式对本发明作进一步的详细说明。显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”“第四”等是用于区别不同的对象，而不是用于描述特定的顺序。此外术语“包括”和“具有”以及他们任何变形，意图在于覆盖不排他的包含。例如包含了一系列步骤或单元的过程、方法、***、产品或设备没有限定于已列出的步骤或单元，而是可包括没有列出的步骤或单元。

现有的软件开发模式，只有在各模块研发完成后，将其进行集合后，才进行相关测试。这样势必会导致最初的一些简单的bug到最后集成后在进行修复，当其牵扯到整个软件的架构时，对其修复就比较难，严重的，甚至会导致整个软件研发从头开始。

本申请的发明人经过研究发现，持续集成开发模式(Continuous Integration，CI)可让软件研发团队在持续的基础上收到反馈并进行改进，不必等到开发周期后期才寻找和修复缺陷。通俗一点儿说，就是指对于开发人员的每一次代码提交，都自动地把Repository中所有代码Check out到一个空目录，并且自动运行所有Test Case。如果成功则接受这次提交，否则告诉团队中成员，这是一个失败的Revision。这种模式可尽快地发现bug并进行早期修复，大大减少集成的问题，降低研发风险，减少重复。

鉴于此，本申请通过从代码的编译与单元测试、到代码组合成模块进行集成测试、再到各模块构成ISO通过PXE技术装机进行***测试，实现了全自动化的持续集成。从不同的测试层面保证了代码的质量和业务逻辑的正确性，有利于缩短研发周期。

在介绍了本发明实施例的技术方案后，下面详细的说明本申请的各种非限制性实施方式。

首先请参见图1，图1为本发明实施例提供的一种基于持续集成的软件包交付方法的流程示意图，本发明实施例可包括以下内容：

S101：从代码审查平台获取审查成功的代码，并将其发送至代码库。

代码代为研发人员用开发工具所支持的语言写出来的源文件，是一组由字符、符号或信号码元以离散形式表示信息的明确的规则体系。代码设计的原则包括惟一确定性、标准化和通用性、可扩充性与稳定性、便于识别与记忆、力求短小与格式统一以及容易修改等。一段代码往往可以实现一个功能，举例来说，由C语言可编译一段实现数据求和的代码，在输入各个进行求和的数后，运行该代码，即可输出这几个数的和的结果。

代码审查平台为自动化测试平台，研发人员将编译完成的一段代码上传至代码审查平台，代码审查平台会对该段代码进行语法、格式等检查。

在一种具体的实施方式中，S101可包括：

S1011：获取用户上传至所述代码审查平台的代码；

S1012：当接收到所述用户对所述代码审阅通过的指令后，对所述代码进行代码格式检查、编译检查以及在所述用户搭建的测试环境中，对所代码进行单元测试；

S1013：将经过代码格式检查、编译检查以及单元测试的代码发送至代码库。

由于代码审查平台进行代码格式检查、编译检查审查是根据具体的规则进行判断，但是毕竟语言是比较灵活的，在机器判断为错误时，可能是正确的；或者某些新型的错误还未入平台的检查规则，这些错误是无法进行排除的。鉴于此，还提供人工进行审阅，既保证代码的质量，又可避免误错而重复之前的提交审查过程，不利于提高研发周期。

在计算机编程中，单元测试针对程序模块(软件设计的最小单位)来进行正确性检验的测试工作。程序单元是应用的最小可测试部件。对于单元测试中单元的含义，一般来说，要根据实际情况去判定其具体含义，如C语言中单元指一个函数，Java里单元指一个类，图形化的软件中可以指一个窗口或一个菜单等。代码往往就是执行一个最小的功能，对代码进行测试可认为是进行单元测试。

S102：当满足预设条件时，在所述代码库中选取不同的代码构建预设格式的软件包，将所述软件包发送至项目软件库，并在用户搭建的测试环境中，对所述软件包进行集成测试。

当满足预设条件时可为：

检测到代码进入所述代码库或当前时间为预设时间。即检测到代码入库或定时进行构建软件包，例如每天的8：00、10：00、12：00、15：00、17：00、18：00以及22：00。

对于定时触发进行集成测试，可根据具体的时间情况进行选取时间段，在研发人员工作时间时，触发的间隔时间较短，而在休息时可间隔时间较长，本申请对此不作任何限定。

预设格式的软件包可为RPM格式的软件包，也可为其他任何格式的包，根据具体的软件实际情况进行生成。构建软件包即将多个代码进行组合成模块，使单一功能的代码组合成实现复合、实用性的模块。举例来说，对于某一网站的登陆界面，需要输出用户名、密码，经过验证后才可登陆。对于实现输入用户名为一组代码、呈现登陆界面为一组代码，验证为一组代码，将其进行组合才可实现登陆的功能。

将构建的软件包发送至项目软件库，例如yun源。

举例来说，S102可为：

S1021：当检测到代码入库时，基于Pipeline任务调度机制触发打包，输出为RPM格式的包；

Pipeline为在NET Framework外接程序编程模型中，表示在外接程序与其宿主之间交换数据的管线段的线性通信模型。

S1022：将RPM软件包发送至软件项目软件库，并更新索引表；

S1023：在测试服务器更新该软件包，并进行集成测试，从而实现持续自动化地集成测试。

其中，RPM版本号通过“git describe”命令获取，输出的.rpm文件上传至项目软件源的“开发库”(即项目软件库)；阶段性的成果发布新的版本，通过将tag上传到源码库这一事件触发，RPM版本号为tag，输出的.rpm文件上传至项目软件源的“稳定库”。根据不同的测试需求，远程连接至要部署的主机，通过运行yum命令更新各模块软件包。最终触发jenkins集成测试任务，针对部署测试环境进行测试。

S103：在所述项目软件库中选取通过集成测试的软件包构建ISO包，通过PXE服务器将所述ISO包安装在物理机上，向所述物理机发送运行测试脚本的指令，以对所述ISO包进行***测试。

ISO包为可在物理机上进行运行的软件包，例如APP。在构建ISO包，可定时(例如每天18：00或22：00)、或随机，或是监控到当前CI***负载较小时，将项目软件库中已经通过集成测试的包进行组合，在添加一些操作***，例如linux，以及运行所需的组件进行构建ISO包。

对于定时触发进行集成测试，可根据具体的时间情况进行选取时间段，在研发人员工作时间时，触发的间隔时间较长，而在休息时可间隔时间较短，本申请对此不作任何限定。

PXE(preboot execute environment，预启动执行环境)用于无盘、有盘联网的网络协议。存放于主板或者网卡上的BIOS或ROM。工作于C/S(Client/Server，客户端/服务器)的网络模式，支持工作站通过网络从远端服务器下载映像，并由此支持通过网络启动操作***，在启动过程中，终端要求服务器分配IP地址，再用TFTP(trivial file transferprotocol，简单文件传输协议)或MTFTP(multicast trivial file transfer protocol)协议下载一个启动软件包到本机内存中执行，由这个启动软件包完成终端基本软件设置，从而引导预先安装在服务器中的终端操作***。PXE可以引导多种操作***。

TFTP为TCP/IP协议族中的一个用来在客户机与服务器之间进行简单文件传输的协议，提供不复杂、开销不大的文件传输服务。由于MTFTP为多点的TFTP服务，而在本申请中只需从网络下载启动软件包到本机内存中即可，故可选用TFTP用于文件传输。

故在将ISO包远程安装到物理机时，可通过PXE技术以及BMC(baseboardmanagement controller，基板管理控制器，一种服务器远程管理器)技术来实现。其中，PXE装机具体实现过程可参阅图2，具体的，可包括：

获取所述用户为PXE服务器配置的文件信息；

工作人员根据实际装机情况修改配置参数。所有的装机配置保存在一个总的配置文件(例如ENV配置文件)中，包括TFTP和挂载有镜像的HTTP服务的地址，各目标主机的MAC、装机后的主机名、IP、网关、***密码等信息。

根据文件信息对DHCP、TFTP以及Kickstart进行配置，并将各自的配置文件发送至相应的服务器中；

为了避免对非目标物理机造成影响，DHCP仅响应在其配置文件中约定的物理机的MAC地址，因此需要根据ENV配置文件中的信息，生成用于HDCP响应的host list，并包含在dhcpd.conf文件中。

由于测试环境会安装不同的镜像或组件，因此会有多个装机启动项，这样就需要根据ENV配置文件为每个物理机在tftp中生成一份独有的引导配置文件，该文件名可为“01-<以-分隔的mac>”。当物理机搜索到DHCP服务器后，会到tftp中读取属于自己的配置文件，并按照该配置文件中配置的引导项进行后续的装机。在tftp中始终保留一个名为default的引导文件，默认告知物理机由硬盘启动，假如目标***找不到属于自己独有的配置文件，将按照默认的default文件中的引导从硬盘启动。该引导配置将指明后续装机的kickstart指导文件。

由于测试环境会安装不同的镜像或组件，因此装机过程不同，这样就需要根据ENV配置文件为不同类型的物理机生成不同的kickstart装机指导文件，这些文件也放于HTTP服务器中。

在配置完成后，启动DHCP、HTTP、TFTP等相关服务。

PXE服务器将ISO包，经过TFTP服务器下载至物理机中；

利用Kickstart服务器将所述ISO包安装至物理机。

可通过SSH方式启动物理机，若物理机不可达，通过IPMI接口重启该物理机的主机。

可使用ping命令轮询检测各物理目标主机的IP是否可通，若通，则说明该主机已经进入装机过程并配置好网卡，此时可以删除TFTP中属于该主机的引导文件，则该主机装机完成重启后会进入TFTP中的default引导由硬盘启动；若不通，则sleep几秒时间继续检测，直至超出最大时长，则说明该主机没有正常进入装机状态，需要进行检查。

各目标物理主机均会在装机完成重启后开启SSH服务，因此可以通过轮询检测ssh到相关主机是否可通来判断是否已经装机完成并重启。

当检测到目标主机已经完成装机并进行重启后，执行ENV配置文件中制定的相关环境准备操作，比如定制化的网络、服务等的配置或预置脚本的执行等，以便进行后续的***测试。对ISO包进行***测试时，可根据工作人员编写的测试脚本进行，例如可根据SDK脚本进行***测试。

整套环境架设于多个网段之中，各网段网络可通。由于DHCP协议无法跨网段响应，因此在各网段部署DHCP服务器或通过DHCP代理的方式实现。各目标物理主机在装机过程中均可以连接到TFTP和HTTP服务器获取配置信息或镜像内容，例如图3所示。

S104：将通过***测试的ISO包交付所述用户。

在本申请提供的技术方案中，从单元测试到集成测试再到装机进行***测试，实现了全自动化的持续集成，不仅提高了代码的质量与业务逻辑的准确性，有效的缩短了研发周期，提高了软件包交付的效率，从而提高了软件开发的效率；而且有效的减少了人力、财力以及物力的投入，具有好的社会经济效率。

请参见图4，图4为本发明实施例提供的另一种基于持续集成的软件包交付方法的流程示意图，在实际操作过程中，在上述实施例的基础上，本申请还提供了有一个具有实际操作意义的实施例，本发明实施例例如可包括以下内容：

S401：具体的与实施例S101所描述一致，此处不再赘述。

S402：当检测到代码进入所述代码库时，在所述代码库中选取不同的代码构建预设格式的软件包，将所述软件包发送至项目软件库，并在用户搭建的测试环境中，对所述软件包进行集成测试。

S403：检测持续集成***的负载数目。

可设置监控装置，实时监测CI***的负载。

S404：当检测到所述持续集成***的负载数目不大于预设阈值时，在所述项目软件库中选取通过集成测试的软件包构建ISO包，通过PXE服务器将所述ISO包安装在多个物理机上，向各个物理机发送运行测试脚本的指令，以对所述ISO包进行***测试。

为了在构建ISO包以及进行***测试时，避免对CI***造成影响，一般选取CI***负载较少，也就是工作量较小时进行。

预设阈值可为3台，当然，也可为其他阈值，具体的可根据实际CI***的性能进行选取。一般来说，晚上时，由于工作人员大都休息，CI***上运行的负载自然较少，故可在晚上进行构建ISO包以及进行***测试。

由于ISO包是可独立运行的软件包，考虑到ISO包的兼容性，可将其安装到多个物理机上，进行***测试。

S405：将通过***测试的ISO包交付所述用户。

由于代码库内存储大量的代码，当代码库建立时间较长时，不可避免的，代码库中会存在相同的代码，所谓相同的代码为同一类编译语言执行功能相同的一组代码。相同的代码不仅占用占用代码的容量，而且还需花费一定的人力进行维护，浪费人力、物力以及财力；此外，为了避免后续进行组合模块，即构建预设格式的软件包时，选取的为同一代码。基于上述实施例，本申请还提供了如下所述的实施例。

判断当前代码是否与所述代码库中的代码相同；

当判定所述当前代码与所述代码库中的代码不相同时，将所述代码发送至所述代码库。

在本申请提供的技术方案中，从单元测试到集成测试再到装机进行***测试，实现了全自动化的持续集成，不仅提高了代码的质量与业务逻辑的准确性，有效的缩短了研发周期，提高了软件包交付的效率，从而提高了软件开发的效率；而且有效的减少了人力、财力以及物力的投入，具有好的社会经济效率。

需要说明的是，在进行上述实施例之前，需要先对持续集成***以及测试环境进行搭建配置，请参见图5，具体可为：

研发人员在工作机上通过git工具上传代码到代码审查工具gerrit；gerrit具有开放的事件流监听接口，zuu通过该接口监听gerrit事件，并根据不同的事件类型(比如上传commit、上传tag、提交comment等)触发位于jenkins中的任务；jenkins为若干主从架构的服务器组成构建集群，其中执行所有的构建任务，部分构建任务由jenkins通过ssh或fabric等方式操作目标服务器完成，包括构建RPM包、构建ISO包以及PXE装机过程。

本发明实施例还针对基于持续集成的软件包交付方法提供了相应的实现装置，进一步使得所述方法更具有实用性。下面对本发明实施例提供的基于持续集成的软件包交付装置进行介绍，下文描述的基于持续集成的软件包交付装置与上文描述的基于持续集成的软件包交付方法可相互对应参照。

请参见图6，图6为本发明实施例提供的基于持续集成的软件包交付装置在一种具体实施方式中的结构图，该装置可包括：

代码入库模块601，用于从代码审查平台获取审查成功的代码，并将其发送至代码库。

集成测试模块602，用于当满足预设条件时，在所述代码库中选取不同的代码构建预设格式的软件包，将所述软件包发送至项目软件库，并在用户搭建的测试环境中，对所述软件包进行集成测试。

***测试模块603，用于在所述项目软件库中选取通过集成测试的软件包构建ISO包，通过PXE服务器将所述ISO包安装在物理机上，向所述物理机发送运行测试脚本的指令，以对所述ISO包进行***测试。

交付模块604，用于将通过***测试的ISO包交付所述用户。

可选的，在本实施例的一些实施方式中，所述***测试模块603可包括：

监控单元6031，用于检测持续集成***的负载数目；

构建单元6032，用于当检测到所述持续集成***的负载数目不大于预设阈值时，在所述项目软件库中选取通过集成测试的软件包构建ISO包。

在本实施例的另一些实施方式中，所述代码入库模块601还包括：

判断单元，用于判断当前代码是否与所述代码库中的代码相同；当判定所述当前代码与所述代码库中的代码不相同时，将所述代码发送至所述代码库。

本发明实施例所述基于持续集成的软件包交付装置的各功能模块的功能可根据上述方法实施例中的方法具体实现，其具体实现过程可以参照上述方法实施例的相关描述，此处不再赘述。

由上可知，本发明实施例从单元测试到集成测试再到装机进行***测试，实现了全自动化的持续集成，不仅提高了代码的质量与业务逻辑的准确性，有效的缩短了研发周期，提高了软件包交付的效率，从而提高了软件开发的效率；而且有效的减少了人力、财力以及物力的投入，具有好的社会经济效率。

本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其它实施例的不同之处，各个实施例之间相同或相似部分互相参见即可。对于实施例公开的装置而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。

专业人员还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。

结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器(RAM)、内存、只读存储器(ROM)、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM、或技术领域内所公知的任意其它形式的存储介质中。

以上对本发明所提供的一种基于持续集成的软件包交付方法及装置进行了详细介绍。本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想。应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以对本发明进行若干改进和修饰，这些改进和修饰也落入本发明权利要求的保护范围内。

Claims (10)

1.一种基于持续集成的软件包交付方法，其特征在于，包括：

从代码审查平台获取审查成功的代码，并将其发送至代码库；

当满足预设条件时，在所述代码库中选取不同的代码构建预设格式的软件包，将所述软件包发送至项目软件库，并在用户搭建的测试环境中，对所述软件包进行集成测试；

在所述项目软件库中选取通过集成测试的软件包构建ISO包，通过PXE服务器将所述ISO包安装在物理机上，向所述物理机发送运行测试脚本的指令，以对所述ISO包进行***测试；

将通过***测试的ISO包交付所述用户。

2.根据权利要求1所述的方法，其特征在于，所述在所述项目软件库中选取通过集成测试的软件包构建ISO包包括：

检测持续集成***的负载数目；

当检测到所述持续集成***的负载数目不大于预设阈值时，在所述项目软件库中选取通过集成测试的软件包构建ISO包。

3.根据权利要求1所述的方法，其特征在于，所述在所述项目软件库中选取通过集成测试的软件包构建ISO包包括：

在预设时间从所述项目软件库中选取通过集成测试的软件包，构建ISO包。

4.根据权利要求3所述的方法，其特征在于，所述预设条件为：

检测到代码进入所述代码库或当前时间为预设时间。

5.根据权利要求1至4任意一项所述的方法，其特征在于，所述通过PXE服务器将所述ISO包安装在物理机上包括：

获取所述用户为所述PXE服务器配置的文件信息；

根据所述文件信息对DHCP、TFTP以及Kickstart进行配置，并将各自的配置文件发送至相应的服务器中；

所述PXE服务器将所述ISO包，经过所述TFTP服务器下载至所述物理机中；

利用所述Kickstart服务器将所述ISO包安装至所述物理机。

6.根据权利要求5所述的方法，其特征在于，所述将其发送至代码库包括：

判断当前代码是否与所述代码库中的代码相同；

当判定所述当前代码与所述代码库中的代码不相同时，将所述代码发送至所述代码库。

7.根据权利要求5所述的方法，其特征在于，所述从代码审查平台获取审查成功的代码，并将其发送至代码库包括：

获取用户上传至所述代码审查平台的代码；

当接收到所述用户对所述代码审阅通过的指令后，对所述代码进行代码格式检查、编译检查以及在所述用户搭建的测试环境中，对所代码进行单元测试；

将经过代码格式检查、编译检查以及单元测试的代码发送至代码库。

8.一种基于持续集成的软件包交付装置，其特征在于，包括：

代码入库模块，用于从代码审查平台获取审查成功的代码，并将其发送至代码库；

集成测试模块，用于当满足预设条件时，在所述代码库中选取不同的代码构建预设格式的软件包，将所述软件包发送至项目软件库，并在用户搭建的测试环境中，对所述软件包进行集成测试；

***测试模块，用于在所述项目软件库中选取通过集成测试的软件包构建ISO包，通过PXE服务器将所述ISO包安装在物理机上，向所述物理机发送运行测试脚本的指令，以对所述ISO包进行***测试；

交付模块，用于将通过***测试的ISO包交付所述用户。

9.根据权利要求8所述的装置，其特征在于，所述***测试模块包括：

监控单元，用于检测持续集成***的负载数目；

构建单元，用于当检测到所述持续集成***的负载数目不大于预设阈值时，在所述项目软件库中选取通过集成测试的软件包构建ISO包。

10.根据权利要求9所述的装置，其特征在于，所述代码入库模块还包括：

判断单元，用于判断当前代码是否与所述代码库中的代码相同；当判定所述当前代码与所述代码库中的代码不相同时，将所述代码发送至所述代码库。