软件程序交付方法、装置、终端及存储介质与流程

本申请涉及持续交付领域，具体而言，涉及一种软件程序交付方法、装置、终端及存储介质。

背景技术：

持续交付(英语：continuousdelivery，缩写为cd)，是一种软件工程手法，让软件产品的产出过程在一个短周期内完成，以保证软件可以稳定、持续的保持在随时可以发布的状况。它的目标在于让软件的构建、测试与发布变得更快以及更频繁。这种方式可以减少软件开发的成本与时间，减少风险。

现有持续交付，每个项目都存在差异性，每个项目若想实现完整的交付流程，则需要根据每个项目的差异性而专门定制对应的交付流程。

使用现有的交付技术方案，需要对每个项目单独设计部署流程，虽然程序有使用共性，但是因为每个项目的复杂性和多样性，每承接一个项目，都需要根据项目的复杂度，花费数天的工作量定制对应的交付模型。

技术实现要素：

本申请的目的在于，针对上述现有技术中的不足，提供一种软件程序交付方法、装置、终端及存储介质，以解决现有技术中不同的项目需要定制不同的交付模型的问题，减小了不同项目交付的复杂程度的问题。

为实现上述目的，本申请实施例采用的技术方案如下：

第一方面，本申请一实施例提供了一种软件程序交付方法，所述方法包括：

确定待交付程序的源代码是否测试通过；

若测试通过，则根据预设的部署配置文件，对所述待交付程序的源代码进行处理，得到目标程序的组件包，所述组件包内包括：多个组件；

将所述组件包上传至预设存储系统中，以使得所述组件对应的目标主机从所述存储系统下载所述组件包，并根据所述部署配置文件进行所述组件的部署。

进一步地，所述若测试通过，则根据预设的部署配置文件，对所述待交付程序的源代码进行处理，得到目标程序的组件包，包括：

若测试通过，则将所述待交付程序的源代码和所述部署配置文件上传至预设编程系统；

在所述预设编程系统中，根据所述的部署配置文件，对所述待交付程序的源代码进行处理，得到所述组件包。

进一步地，所述部署配置文件包括：配置部分、业务应用服务控制脚本部分和业务应用服务流程化部署脚本部分；

其中，所述配置部分包括：组件代码地址、组件部署的目标主机的信息、组件包的存储地址；

所述业务应用服务控制脚本部分包括：编译脚本、自动化测试脚本和自动化代码质量检查脚本；

所述脚本部分包括：启动脚本、停止脚本、健康检查脚本、目标主机部署配置信息以及目标主机部署执行脚本。

进一步地，所述根据所述部署配置文件，对所述待交付程序的源代码进行处理，得到所述组件包，包括：

根据所述部署配置文件中的所述编译信息，对所述源代码进行编译，得到所述目标程序的多个所述组件；

对多个所述组件进行打包，得到所述组件包。

进一步地，所述组件包还包括：每个所述组件的版本信息；所述对多个所述组件进行打包，得到所述组件包，包括：

确定每个所述组件的版本信息；

对多个所述组件和每个所述组件的版本信息进行打包，得到所述组件包。

进一步地，所述将所述组件包上传至预设存储系统中之前，所述方法还包括：

根据所述组件包的存储地址，确定所述存储系统。

进一步地，所述确定待交付程序的源代码是否测试通过，包括：

分别获取所述待交付的源代码进行自动化代码质量检查的检查结果及自动化测试的测试结果；

根据所述检查结果，确定所述自动化代码质量检查是否通过；

根据所述测试结果，确定所述自动化测试是否成功；

若所述自动化代码质量检查通过，且所述自动化测试成功，则确定测试通过。

第二方面，本申请另一实施例提供了一种软件程序交付装置，所述装置包括：第一确定模块、处理模块和上传模块，其中：

所述第一确定模块，用于确定待交付程序的源代码是否测试通过；

所述处理模块，用于若测试通过，则根据预设的部署配置文件，对所述待交付程序的源代码进行处理，得到目标程序的组件包，所述组件包内包括：多个组件；

所述上传模块，用于将所述组件包上传至预设存储系统中，以使得所述组件对应的目标主机从所述存储系统中下载所述组件包，并根据所述部署配置文件进行所述组件的部署。

进一步地，所述处理模块，还用于若测试通过，则将所述待交付程序的源代码和预设部署配置文件上传至预设编程系统；

在所述预设编程系统中，根据预设的部署配置文件，对所述待交付程序的源代码进行处理，得到目标程序的组件包。

进一步地，所述处理模块，还用于根据所述部署配置文件中的所述编译信息，对所述源代码进行编译，得到所述目标程序的多个所述组件；

对多个所述组件进行打包，得到所述组件包。

进一步地，所述处理模块，还用于确定每个所述组件的版本信息；

对多个所述组件和每个所述组件的版本信息进行打包，得到所述组件包。

进一步地，所述装置还包括第二确定模块，用于根据所述组件包的存储地址，确定所述存储系统。

进一步地，所述确定模块，还用于分别获取所述待交付的源代码进行自动化代码质量检查的检查结果及自动化测试的测试结果；

根据所述检查结果，确定所述自动化代码质量检查是否通过；

根据所述测试结果，确定所述自动化测试是否成功；

若所述自动化代码质量检查通过，且所述自动化测试成功，则确定测试通过。

第三方面，本申请另一实施例提供了一种程序交付终端，包括：处理器、存储介质和总线，所述存储介质存储有所述处理器可执行的机器可读指令，当计算机设备运行时，所述处理器与所述存储介质之间通过总线通信，所述处理器执行所述机器可读指令，以执行如上述第一方面任一所述方法的步骤。

第四方面，本申请另一实施例提供了一种存储介质，所述存储介质上存储有计算机程序，所述计算机程序被处理器运行时执行如上述第一方面任一所述方法的步骤。

本申请的有益效果是：采用本申请提供的软件程序交付方法，可以通过根据预设的部署配置文件，对通过测试的待交付程序的源代码进行处理，得到目标程序的组件包，并将组件包上传至预设存储系统中，可使得组件对应的目标主机从存储系统下载该组件包，根据预先获取的该部署配置文件进行该组件的配置。该方法中，组件包是根据预设的部署配置文件对待交付程序的源代码进行处理后生成的，目标主机在获取该组件包后，可根据部署配置文件进行该组件包中对应组件的部署，对待交付程序只需具有部署配置文件即可，无需针对不同的程序交付项目定制不同的交付模型，减小了不同程序交付项目的交付复杂程度，提高了软件程序的交付效率。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1为本申请一实施例提供的软件程序交付方法的流程示意图；

图2为本申请另一实施例提供的软件程序交付方法的流程示意图；

图3为本申请一实施例提供的软件程序交付装置的结构示意图；

图4为本申请另一实施例提供的软件程序交付终端的结构示意图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。

本申请提供一种软件程序交付方法，对待交付程序只需具有部署配置文件即可，无需针对不同的程序交付项目需要定制不同的交付模型，减小了不同软件交付项目的交付复杂程度，大大缩短了程序交付的工期，提高了软件程序的交付效率，还可有效保证整个程序交付过程的稳定度。

图1为本申请一实施例提供的一种软件程序交付方法的流程示意图。该软件程序交付方法可由程序交付终端执行，该程序交付终端可以为：笔记本电脑、台式电脑，平板电脑中的任一项，或是其他任一类型的计算机设备。如图1所示，该方法可包括：

s101：确定待交付程序的源代码是否测试通过。

该待交付程序可以为网页版应用程序、客户端应用程序、插件程序或者其它类型的程序。

需要说明的是，终端接收到用户提交的待交付程序源代码后，按照预设测试规则，对待交付程序的源代码进行测试，以确定该源代码是否测试通过；也可获取预先执行的测试过程的测试结果，根据该测试结果，确定该源代码是否测试通过。若测试通过，便可继续执行下一步。若测试不通过，则可显示测试不通过的原因和/或出现错误的代码所在的位置等信息。

在该软件程序交付方法中，还可获取该待交付程序的交付参数，并确定该交付参数是否满足参数的预设条件。该预设条件可以为参数的合理性条件。该交付参数可以为用户输入的参数，其中，用户输入的参数可以是从预先设置的参数库中选择的该待交付程序对应的参数。该交付参数包括下述至少一个参数：待交付程序的代码版本、待交付程序的运行分支数等。

在获取该交付参数后，终端可确定交付参数是否满足预设条件，例如：判断代码版本是否满足预设版本条件。终端还可确定该待交付程序的运行环境是否在预设的运行环境库中，如确定该待交付程序的运行环境是否为视窗(windows)操作系统、安卓(android)或苹果操作系统(ios)等任一预设的操作系统。

若该源代码测试通过、该待交付程序的交付参数满足预设的条件，并且该待交付程序的运行环境在预设的运行环境库中，则可执行下述s102，根据部署配置文件，对待交付程序的源代码进行处理，得到目标程序的组件包。

该方法中，还需要判断该待交付程序的交付参数是否满足预设条件，判断该待交付程序的运行环境是否在预设的运行环境库中，在上述判断的判断结果均通过，且源代码测试也通过的情况下，才可执行后续步骤。这样可有效保证后续步骤的安然进行，保证程序交付的顺利执行。

s102：若测试通过，则根据预设的部署配置文件，对待交付程序的源代码进行处理，得到目标程序的组件包。

其中，组件包也可称为组件整理包，其可包括：多个组件。

该方法中，可根据该部署配置文件，对该源代码依次进行编译、打包，从而得到包括该多个组件的组件包。

s103：将组件包上传至预设存储系统中，以使得组件对应的目标主机从存储系统下载组件包，并根据部署配置文件进行组件的部署。

需要说明的是，预设存储系统可以为中间件存储系统，其可以为yar存储系统、tair存储系统、tddl存储系统、tfs存储系统、云存储系统等中的任一存储系统，但并不以此为限。

将组件包上传至预设存储系统，可以实现对不同云的对接，为目标主机后续的部署做准备，其中，不同云的对接是指多种云(混合云)的统一组件包下载入口。

在将该组件包上传至该存储系统后，目标主机需要部署时，就可直接从该存储系统中下载该组件包，并根据预先获取的该部署配置文件进行组件的部署。

本实施例中，可以通过根据预设的部署配置文件，对通过测试的待交付程序的源代码进行处理，得到目标程序的组件包，并将组件包上传至预设存储系统中，可使得组件对应的目标主机从存储系统下载该组件包，根据预先获取的该部署配置文件进行该组件的配置。该方法中，组件包是根据预设的部署配置文件对待交付程序的源代码进行处理后生成的，目标主机在获取该组件包后，可根据部署配置文件进行该组件包中对应组件的部署，对待交付程序只需具有部署配置文件即可，无需针对不同的程序交付项目定制不同的交付模型，减小了不同程序交付项目的交付复杂程度，提高了软件程序的交付效率。

图2为本申请另一实施例提供的软件程序交付方法，如图2所示，步骤s102可包括：

s201：分别获取待交付的源代码进行自动化代码质量检查(qatest)的检查结果及自动化测试(autotest)的测试结果。

s202：根据检查结果，确定自动化代码质量检查是否通过。

其中，自动化代码质量检查可以覆盖多种代码质量问题，可以提升代码的开发效率，同时降低人工代码检查的成本。自动化代码质量检查中的自动化，是指在代码规范的基础上，使用自动化工具进行质量检查，质量检测的部分通常包括下述至少一个检查项：代码规范检查、重复率检查、复杂度检查，检查覆盖度。其中，代码规范检查包括：风格规范、实践规范、业务规范中的至少一项规范检查。重复率检查包括：重复出现的代码区块占比的检查，在检查过程中，若重复出现的代码区块占比在5％以下，则可确定代码区块占比的检查通过。复杂度检查可包括：总行数、模块大小、循环复杂度等至少一项检查。检查覆盖度可包括：经过检查的行数占代码库总行数的比例。

s203：根据测试结果，确定自动化测试是否成功。

自动化测试即测试代码是否可以正常运行成功。若代码运行出现故障(bug)，则可确定代码无法正常运行，即自动化测试失败。

在应用中，可实时监听该源代码的变化，当监听到源代码中具有发布(push)事件或合并(merge)事件，则可触发进行上述自动化代码质量检查，以及自动化测试。

s204：若自动化代码质量检查通过，且自动化测试成功，则确定测试通过。

具体地，只有通过自动化代码质量检查，和自动化测试的情况下，才会返回测试通过的结果，此时流程可以继续执行下一步。若自动化代码质量检查和自动化测试中，存在任一测试未通过，则均返回测试未通过的结果，此时需要用户重新修改代码并提交测试，直至两个测试均通过，流程才能继续执行下一步。

需要说明的是，每次源代码有更新或者修改时，都需要对修改后的源代码重新进行测试，测试通过后再进行后续操作。

具体执行中，可在测试结果检查(testresultcheck)阶段，执行上述s201-s204的各步骤。

可选的，步骤s102可包括：若测试通过，则将待交付程序的源代码和部署配置文件上传至预设编程系统；在该预设编程系统中，根据该部署配置文件，对该待交付程序的源代码进行处理，得到该组件包。

其中，预设编程系统由已配各种语言编译环境的主机组成。，在预设编程系统中，终端可根据预设的部署配置文件，采用该编程系统对待交付程序的源代码进行处理，得到目标程序的多个组件；并对多个组件进行打包，从而得到组件包。

可选的，如上所示的部署配置文件可以从上述编程系统中获取，其可包括：配置(config)部分、业务应用服务控制脚本业务应用服务控制脚本(bin)部分和业务应用服务流程化部署脚本(script)部分。

其中，配置部分包括：组件代码地址、组件部署的目标主机的信息、组件包的存储地址；业务应用服务控制脚本部分包括：编译脚本、自动化测试脚本和自动化代码质量检查脚本；业务应用服务流程化部署脚本部分包括：启动脚本、停止脚本、健康检查脚本、目标主机部署配置信息以及目标主机部署执行脚本。

其中，健康检查脚本，用于判断并检查业务应用服务状态是否启动成功、是否存活、是否健康；目标主机部署配置信息，用于该配置集中管理，会被其他脚本引用；目标主机部署执行脚本，用于定义业务应用服务部署执行中的一些事情，包含组件包的下载、解压、安装、备份等操作。

部署配置文件的设置，分离出了各个项目差异之间共有的特性，使得针对每个不同项目的交付流程而言，只需要根据实际情况少量修改部署配置文件中对应信息，就可以实现不同程序交付项目之间的灵活对接。

可选的，在步骤s103之前，该方法还可包括：根据该部署配置文件中组件包的存储地址，确定存储系统。

具体地，组件包中包含有组件包的存储地址，其中，存储地址用于指示该组件包对应的目标存储系统，其中，存放系统可以为下述存储系统中的任一项：yar存储系统、tair存储系统、tddl存储系统、tfs存储系统。存储系统的选择可由该部署配置文件中组件包的存储地址所决定。

可选地，步骤s102可包括：根据部署配置文件中的编译信息，对源代码进行编译，得到目标程序的多个组件；并对多个组件进行打包，得到组件包。

需要说明的是，组件包中还包括每个组件的版本信息，确定每个组件的版本信息后，对多个组件和每个组件的版本信息进行打包，得到组件包。

该方法中，在上传(upload)阶段，可将部署配置文件随源代码一起上传至预设编程系统，用以得到组件包，由于部署配置文件的修改、维护等，有效提高了代码的易修改性、统一维护性以及灵活性。

部署(deploy)阶段，目标主机可根据预设的版本信息，从存储系统下载该组件包，同时从预设编程系统中下载部署配置文件，按照部署配置文件中定义的目标主机的部署脚本对该组件包中该目标主机所对应的组件进行部署。

并且，该方法中，对多个组件和每个组件的版本信息进行打包，得到组件包，可使得目标主机基于预设的版本信息下载组件包，用以进行准确的组件部署。

可选地，部署阶段中，可以采用迭代式部署方法：第一次部署总量的20％，第二次部署剩余总量的20％，第三次再部署剩余总量的20％……，直至组件全部部署完成。这样的部署方法相对于一次性组件部署的方法，减少了组件部署失败的风险(一次性部署的方法中，一个失败可能会导致全部部署失败，风险较高)。具体的部署阶段中，可根据用户需要选择，设置迭代式部署每次部署的占比，例如迭代式部署也可一次部署总量的百分之十或者百分之十五，或者任意整数，在此并不做任何限制。

部署阶段完成后，进入release阶段：release阶段是部署后的收尾操作，用于实现代码版本信息的标记、部署结果的反馈等操作。release阶段完成后，整个交付流程结束。

本实施例中，采用本申请提供的软件程序交付方法，可以通过根据预设的部署配置文件，对通过测试的待交付程序的源代码进行处理，得到目标程序的组件包，并将组件包上传至预设存储系统中，可使得组件对应的目标主机从存储系统下载该组件包，根据预先获取的该部署配置文件进行该组件的配置。该方法中，组件包是根据预设的部署配置文件对待交付程序的源代码进行处理后生成的，目标主机在获取该组件包后，可根据部署配置文件进行该组件包中对应组件的部署，对待交付程序只需具有部署配置文件即可，无需针对不同的程序交付项目定制不同的交付模型，减小了不同程序交付项目的交付复杂程度，提高了软件程序的交付效率，并且提高了易修改性、统一维护性以及灵活性。

图3为本申请一实施例提供的软件程序交付装置的结构示意图，如图3所示，该装置包括：第一确定模块301、处理模块302和上传模块303，其中：

第一确定模块301，用于确定待交付程序的源代码是否测试通过。

处理模块302，用于若测试通过，则根据预设的部署配置文件，对待交付程序的源代码进行处理，得到目标程序的组件包，组件包内包括：多个组件。

上传模块303，用于将组件包上传至预设存储系统中，以使得组件对应的目标主机从存储系统中下载组件包，并根据部署配置文件进行组件的部署。

进一步地，处理模块302，还用于若测试通过，则将待交付程序的源代码和预设部署配置文件上传至预设编程系统；在预设编程系统中，根据预设的部署配置文件，对待交付程序的源代码进行处理，得到目标程序的组件包。

进一步地，处理模块302，还用于根据部署配置文件中的编译信息，对源代码进行编译，得到目标程序的多个组件；对多个组件进行打包，得到组件包。

进一步地，处理模块302，还用于确定每个组件的版本信息；对多个组件和每个组件的版本信息进行打包，得到组件包。

进一步地，确定模块303，还用于分别获取待交付的源代码进行自动化代码质量检查的检查结果及自动化测试的测试结果；根据检查结果，确定自动化代码质量检查是否通过；根据测试结果，确定自动化测试是否成功；若自动化代码质量检查通过，且自动化测试成功，则确定测试通过。

上述装置用于执行前述实施例提供的方法，其实现原理和技术效果类似，在此不再赘述。

以上这些模块可以是被配置成实施以上方法的一个或多个集成电路，例如：一个或多个特定集成电路(applicationspecificintegratedcircuit，简称asic)，或，一个或多个微处理器(digitalsingnalprocessor，简称dsp)，或，一个或者多个现场可编程门阵列(fieldprogrammablegatearray，简称fpga)等。再如，当以上某个模块通过处理元件调度程序代码的形式实现时，该处理元件可以是通用处理器，例如中央处理器(centralprocessingunit，简称cpu)或其它可以调用程序代码的处理器。再如，这些模块可以集成在一起，以片上系统(system-on-a-chip，简称soc)的形式实现。

图4为本申请另一实施例提供的程序交付终端的结构示意图，该程序交付终端可以集成于终端设备或者终端设备的芯片。

该程序交付终端包括：处理器501、存储介质502和总线503。

处理器501用于存储程序，处理器501调用存储介质502存储的程序，以执行上述方法实施例。具体实现方式和技术效果类似，这里不再赘述。

可选地，本申请还提供一种程序产品，例如存储介质，该存储介质上存储有计算机程序，包括程序，该程序在被处理器运行时执行上述方法实施例。

在本申请所提供的几个实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。

上述以软件功能单元的形式实现的集成的单元，可以存储在一个计算机可读取存储介质中。上述软件功能单元存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(英文：processor)执行本申请各个实施例所述方法的部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(英文：read-onlymemory，简称：rom)、随机存取存储器(英文：randomaccessmemory，简称：ram)、磁碟或者光盘等各种可以存储程序代码的介质。