CN108388445B - 一种基于“平台+应用”模式的持续集成方法 - Google Patents

Abstract

一种基于“平台+应用”模式的持续集成方法，具体包括以下步骤：抽象出平台和应用；资源配置统一管理；平台和产品发布包也作为一种资源进行统一配置管理，信息存储采用xml格式，并统一以web方式展现；定义平台、产品，并准备构建模板、部署测试模板、测试用例；平台自动集成构建；平台自动部署测试；多个产品的软件集成构建；产品自动部署测试。本发明增强了各产品的底层――即平台的稳定性，加速了软件持续集成速度，提高了产品开发的效率和正确率，缩短了开发的周期，适用于框架分层结构清晰的软件族群的协调开发。

Description

一种基于“平台+应用”模式的持续集成方法

技术领域

本发明应用于大型软件研发领域，包括Linux、UNIX、Win等操作系统上的大型软件开发，特别适合具有多自动化软件产品群的开发过程。

背景技术

随着社会发展，软件尤其是各行业软件的规模越来越大，包含的模块也越来越多，相互联系合作性也越来越强，持续地集成(Continuous Integration)在软件开发过程中也越来越重要。持续集成，起源于敏捷软件开发中的极限编程思想，是完全地自动化地构建过程，使得一个开发团队在一天中多次构建并测试软件。持续集成鼓励软件开发项目团队在一个周期内(如一天)多次提交代码，同时保证每次签入操作都不会损害已经通过的构建。这样及时发现问题，减少风险，减少重复工作，降低部署难度，对于管理者来说也增加项目的可见性。

一般来说，一个公司的软件产品都不只一个，都是一个软件产品群，这些软件相互关联，有些有交互接口，甚至有些软件的部分代码功能都完全相同，这样完全可以整合出一个内部公共软件平台，在此平台基础上二次开发面向市场的产品，这种情形下，持续集成如果还是按照通常惯例来进行(从所有源码到一个软件发布包进行部署测试，再下一个软件集成)，就存在重复代码重复测试重复缺陷bug等问题。针对这种情况，本发明提出了一种基于“平台+应用”模式的持续集成方法，即加快了产品的集成速度，较低了风险，也大大稳定了内部平台，减少对外软件产品的缺陷bug。

发明内容

本发明是在统一规划设计软件群的基础上，提出了“平台+应用”模式的持续集成方法，来稳定通用平台功能，加快多个产品的持续集成速度，减少各软件产品的缺陷。本发明的持续集成方法能够较少开发量，增强各产品底层功能的稳定性，加快一个公司内各软件产品的集成速度。

为了更好地理解本发明的技术方案，首先对本发明中所出现的技术术语说明如下。

持续集成的几个要素：统一代码等资源管理、自动快速构建(即编译打包发布)、模拟生产环境的自动测试、自动化的部署。并且做到每个人都很容易地获取最新可执行的软件发布包，都知道项目当前进展。

平台：在各软件产品的设计阶段中，梳理各产品的需求，在通用架构或功能层次上进行抽象，并建立二次开发机制应对各产品需求的差异，形成一个通用平台。平台的抽象，其实质是软件可复用性设计的一个具体体现，使得建立在此平台上的各应用产品可以把关注点放在产品需要实现的数据流、逻辑等问题上，而不需关心底层实现的细节(如怎么消息通讯，怎么实时数据共享等)，提高了软件开发的效率和正确率，缩短了开发的周期。

应用：对多个产品抽象的，面向用户直接需求的功能集。

产品：是在平台基础上的包含一个或多个应用的软件，是一个具体的产品，直接提供给用户使用的一个完整的软件发布。

本发明具体采用以下技术方案：

一种基于“平台+应用”模式的持续集成方法，其特征在于，所述持续集成方法包括以下步骤：

步骤1：首先在各软件产品的设计阶段进行统一规划，梳理软件需求，在架构上或功能上进行抽象，提取各产品共有功能或属性为平台，提取部分产品共有功能或属性为应用,并且在设计平台时增加支持二次开发的设计需求；

步骤2：建立资源服务器对以下资源进行集中管理：平台、应用的源代码、各产品的测试用例、配置文件、所用到的第三方组件或动态库、数据库定义、用于初始化工程的数据文件、产品搭建脚本、产品搭建运行环境的配置文件或安装脚本；

步骤3：将平台和各产品的各版本的发布包作为一种资源进行统一配置管理，以版本号、平台名称、产品名称、运行的操作系统名称为关键字，信息存储采用xml格式，并统一以web方式展现，在后续的产品持续集成中使用；

步骤4：定义产品包含哪些应用，基于哪个平台；编写平台、产品构建模板，包括编译打包脚本、发布包使用的安装脚本；定义各平台、产品的部署测试模板、测试用例，定义产品构建模板；

步骤5：使用统一发布工具，执行步骤4定义的平台构建模板自动执行软件集成，自动构建出特定版本号的各操作系统的平台安装发布包，并自动提交资源服务器统一管理，并自动采用邮件等方式通知相关人员；

步骤6：执行步骤4定义的平台部署测试模板，对平台发布包进行单独的自动部署，进行自动测试；若测试发现缺陷，即为多产品共有缺陷，则修改平台代码、配置或第三方包，再返回步骤5进行迭代集成构建；

步骤7：开始产品的集成构建，使用统一发布工具，选择集成所使用的平台发布包版本号，执行步骤4中定义的产品构建模板来自动进行软件集成；

步骤8：进行产品软件自动部署测试，根据步骤4定义的产品部署测试模板，对各产品发布包进行单独的自动部署，自动测试，若发现缺陷，修改产品或平台的代码、配置，当修改的是产品的代码、配置，则修改后返回步骤7；当修改的是平台的代码、配置，则修改后返回步骤5进行迭代集成构建；

步骤9：集成构建产品补丁，以SVN修改记录、新编译结果文件来共同确定补丁中包含哪些文件，并在制作过程中采用了创建基准文件的方式来自动挑选确定补丁包中的内容。

本发明进一步包括以下优选方案：

在步骤1中，各产品共有功能或属性可以包括但不限于：需要开发的各自动化产品都必要的字符串通用操作库、基本统计函数库、监控基本处理流程库、通讯底层封装库、实时数据库、消息总线。

所述支持二次开发的设计需求包括但不限于二次开发接口。在步骤2中，所述资源服务器支持网站查询浏览。

在步骤4中，编译打包脚本采用JavaScript语言来定义平台、产品的编译和打包制作的过程；安装脚本采用Lua语言定义各发布包的自动安装过程。

在步骤5中，通过平台构建模板自动执行软件集成的具体流程如下：

5.1从代码库(SVN)获取平台代码；

5.2从第三方库获取平台第三方资源压缩包并解压

5.3执行代码的编辑脚本；

5.4当是大版本制作时，根据配置选择相关文件进行压缩，并写入版本号、各SVN号等信息；

5.5当是补丁制作时，选择比基准文件时间新的文件进行压缩，并写入版本号、各SVN号等信息；

5.6制作自有格式的各操作系统上的软件安装包；

5.7软件安装包提交资源服务器，进行统一资源管理，并通过邮件方式通知相关人员。

在步骤7中，产品的集成构建流程如下：

7.1根据产品构建模板的打包脚本从资源服务器获取指定版本号的平台发布包，并解压平台但不执行安装脚本；

7.2从代码库(SVN)获取产品代码，所述产品代码包含多个SVN地址，包含多个应用代码；

7.3从第三方库获取产品第三方资源压缩包并解压；

7.4执行编辑脚本；

7.5当是大版本制作时，根据配置选择相关文件进行压缩，并写入版本号、各SVN号等信息；

7.6当是补丁制作时，选择比基准文件时间新的文件进行压缩，并写入版本号、各SVN号等信息；

7.7制作自有格式的各操作系统上的产品安装包；

7.8将产品安装包提交资源服务器进行统一管理，并通过邮件方式通知相关人员。

本发明具有以下有益的技术效果：

本发明针对软件族群的功能特点，对问题提出了更高层的抽象，抽象出平台和应用，使得多产品间共性的问题统一解决，在此基础上的持续集成也利用此特性，进行“平台+应用”的多层次配合的持续集成，提高了软件开发的效率和正确率，缩短了开发的周期。

附图说明

下面结合附图及具体实施例对本发明再作进一步详细的说明，

图1为本发明基于“平台+应用”模式的持续集成方法的流程示意图；

图2是平台、应用、产品的关系示例图；

图3是平台的构建脚本流程；

图4是产品的构建脚本流程。

具体实施方式

下面结合说明书附图对本发明的技术方案做进一步详细介绍。

如图1所示为本发明基于“平台+应用”模式的持续集成方法的流程示意图，本发明基于“平台+应用”模式的持续集成方法包括以下步骤：

步骤1：首先在各软件产品的设计阶段进行统一规划，梳理软件需求，在架构上或功能上进行抽象，提取各产品共有功能或属性为平台，提取部分产品共有功能或属性为应用,并且在设计平台时增加支持二次开发的设计需求，其中各产品共有功能或属性可以包括但不限于：需要开发的各自动化产品都必要的字符串通用操作库、基本统计函数库、监控基本处理流程库、通讯底层封装库、实时数据库、消息总线，所述支持二次开发的设计需求包括但不限于二次开发接口。

先部署资源服务、产品发布服务、自动更新服务(可部署在同一台机器上)，搭建各操作系统的编译机器(包括各编译环境)，在任意计算机上安装此系统的控制端软件，然后：

首先进行平台和应用的抽象。在产品需求分析阶段，对多个产品的需求功能进行对比，发现相同或类似需求的功能。所有产品都具有的需求提取为平台需求，成立平台的开发项目；几个产品具有的需求提取为应用需求。在平台设计阶段，增加应用类型，并设计按应用提供不同功能。

比如：平台提供的实时库中各库、表、字段属于多个不同应用区分，以某个应用角度访问时，实时库只有属于此应用的库、表、字段，如此做到每个包含不同应用的产品，在运行时其实时库结构是不同的。类似的进程、术语、节点类型等等都可以属于不同应用。

平台、应用和产品关系示例如图2，一个具体产品可以在平台基础上包含多个应用。每次产品都有如下文件来定义包含哪些应用。

[SYSTEM]

appdef＝SCADA,HMI,FIS

表示本产品包含3个应用：SCADA、HMI、FIS

同时，在各产品的软件设计阶段，对大量重复的编码，通用函数放到平台中实现设计，以此来增强软件的复用性，减少开发量。

步骤2：建立资源服务器对以下资源进行集中管理：平台、应用的源代码、各产品的测试用例、配置文件、所用到的第三方组件或动态库、数据库定义、用于初始化工程的数据文件、产品搭建脚本、产品搭建运行环境的配置文件或安装脚本；所述资源服务器支持网站查询浏览。

源代码、代码相关的数据文件、配置文件采用SVN方式管理；其他资源采用统一发布工具ftp方式管理各配置资源，在其上定义各资源信息，包括其版本号、操作系统等，

如第三方库等，其信息xml示例如下：

<DevSoftWare name＝"CSGC3000ThirdParty"desc＝"CSGC3000平台使用的第三方包资源">

<versions ver＝"1.0"desc＝"">

<resource id＝"1"ostype＝"WINDOWS"osVer＝""vbit＝"32"href＝"csgc3000_winxp_thirdparty.zip"/>

<resource id＝"2"ostype＝"REDHATLINUX"osVer＝""vbit＝"32"href＝"csgc3000_redhat5.3_thirdparty.zip"/>

</versions>

<versions ver＝"2.0"desc＝"">

…………

</versions>

</DevSoftWare>

步骤3：将平台和各产品的各版本的发布包作为一种资源进行统一配置管理，以版本号、平台名称、产品名称、运行的操作系统名称为关键字，信息存储采用xml格式，并统一以web方式展现，在后续的产品持续集成中使用；

平台和各产品的各版本的发布包也作为一种资源进行统一配置管理，以版本号、平台名称、产品名称、运行的操作系统名称为关键字，信息存储采用xml格式，并统一以web方式展现，在后续的产品持续集成中使用。

采用tomcat、ftp方式建立产品发布服务器来提供平台和各产品的发布包管理服务。信息存储采用xml格式，并统一以web方式展现。示例如下：

<name>CSGC3000For WINDOWS</name>

<Component>

<name>2.3.8大版本.32位WINDOWS 7版本</name>

<url>ftp://ftpuser:ftpuser@192.188.80.13/version_release/distribution_csgc3000trunk/csgc3000-V2.3.8-72677-WINDOWS_7-32bit.SDK-Beta.exe</url>

<desc>CSGC-3000V2.3.8 32bit,开普测试编译环境：VS2010,Qt4.8.6-32bit</desc>

<patch>0</patch>

<version>2.3.8 32位</version>

<svn>72677</svn>

<time>2016.08.11</time>

<osversion>7</osversion>

<md5>88d925d209db64764a0e6daeaf22c757</md5>

</Component>

步骤4：定义产品包含哪些应用，基于哪个平台；编写平台、产品构建模板，包括编译打包脚本、发布包使用的安装脚本；定义各平台、产品的部署测试模板、测试用例，定义产品构建模板；编译打包脚本采用JavaScript语言来定义平台、产品的编译和打包制作的过程；安装脚本采用Lua语言定义各发布包的自动安装过程。在统一发布工具中定义平台和产品关系，信息xml示例如下：

<application name＝"MASTER"base＝"nuplat"

packnamer＝"％softname％-V％ver％-％svn％-％ostype％-％vbit％bit">

(即：产品MASTER是建立在nuplat平台上)

并准备构建模板、部署测试模板、测试用例。其中平台的构建脚本采用JavaScript语言来定义构建流程。

其中产品的构建脚本中采用JavaScript来定义构建流程。

步骤5：使用统一发布工具，执行步骤4定义的平台构建模板自动执行软件集成，自动构建出特定版本号的各操作系统的平台安装发布包，并自动提交资源服务器统一管理，并自动采用邮件等方式通知相关人员；

根据事先定义的平台构建模板(包括平台脚本、安装脚本)进行软件集成，采用统一发布工具自动远程运行相应的构建模板，构建出平台安装发布包。自动执行过程的具体流程如附图3。即：

在步骤5中，通过平台构建模板自动执行软件集成的具体流程如下：5.1从代码库(SVN)获取平台代码；(即图3中B.搭建编译目录的发布大版本分支)5.2从第三方库获取平台第三方资源压缩包并解压

5.3执行代码的编辑脚本；(即图3中C步骤)

包括设置编译参数、临时环境变量、编译

5.4当是大版本制作时，根据配置选择相关文件进行压缩，并写入版本号、各SVN号等信息；(即图3中E形成数据压缩包的大版本分支)

5.5当是补丁制作时，选择比基准文件时间新的文件进行压缩，并写入版本号、各SVN号等信息；(即图3中E形成数据压缩包的补丁分支)

5.6制作自有格式的各操作系统上的软件安装包；

5.7软件安装包提交资源服务器，进行统一资源管理，并通过邮件方式通知相关人员。

步骤6：执行步骤4定义的平台部署测试模板，对平台发布包进行单独的自动部署，进行自动测试；若测试发现缺陷，即为多产品共有缺陷，则修改平台代码、配置或第三方包，再返回步骤5进行迭代集成构建；增强平台的稳定性，增强后期多产品的稳定性。

步骤7：开始产品的集成构建，使用统一发布工具，选择集成所使用的平台发布包版本号，执行步骤4中定义的产品构建模板来自动进行软件集成；

在实用时，可以选择集成所使用的平台发布包的版本号，采用统一发布工具自动远程运行相应模板，根据事先定义的产品构建模板(包括打包脚本、安装脚本)来持续集成，自动生成发布包。发布包中即包含版本信息，由包含平台、产品(多应用)的SVN信息，补丁包也包含每次获取时的SVN信息，大版本信息。

自动执行过程的具体流程如图4。大致流程类似平台安装发布包的制作，但在B.搭建编译目录中增加了一个步骤：a.获取平台的发布包，如此将平台和产品结合在一起编译发布。即如下说明：

7.1根据产品构建模板的打包脚本从资源服务器获取指定版本号的平台发布包，并解压平台但不执行安装脚本；(即图4中B.搭建编译目录的发布大版本分支)

7.2从代码库(SVN)获取产品代码，所述产品代码包含多个SVN地址，包含多个应用代码；(即图4中B.搭建编译目录的发布大版本分支)

7.3从第三方库获取产品第三方资源压缩包并解压；

7.4执行编辑脚本；(即图4中C步骤)

7.5当是大版本制作时，根据配置选择相关文件进行压缩，并写入版本号、各SVN号等信息；(即图4中E.形成数据压缩包的大版本分支)

7.6当是补丁制作时，选择比基准文件时间新的文件进行压缩，并写入版本号、各SVN号等信息；(即图4中E.形成数据压缩包的补丁分支)

7.7制作自有格式的各操作系统上的产品安装包；

7.8将产品安装包提交资源服务器进行统一管理，并通过邮件方式通知相关人员。

步骤8：进行产品软件自动部署测试，根据步骤4定义的产品部署测试模板，对各产品发布包进行单独的自动部署，自动测试，若发现缺陷，修改产品或平台的代码、配置，当修改的是产品的代码、配置，则修改后返回步骤7；当修改的是平台的代码、配置，则修改后返回步骤5进行迭代集成构建；

步骤9：集成构建产品补丁，以SVN修改记录、新编译结果文件来共同确定补丁中包含哪些文件，并在制作过程中采用了创建基准文件的方式来自动挑确定补丁包中的内容。

对于需要发布补丁包的产品，在步骤4中构建模板中就需要考虑到。一般以某段时间的SVN修改记录、新编译结果文件来共同确定补丁包包含哪些文件，并在制作过程中采用了创建基准文件的方式来自动挑确定补丁包中的内容。具体流程如下：

9.1在搭建编译目录时判断是否是发布大版本；

9.2若不是大版本则是制作补丁，就需要先获取大版本的发布包，再进行SVN获取程序覆盖到相同目录，并创建时间标记文件；(即图3、图4中B搭建编译目录的补丁分支)

9.3然后根据大版本对应的SVN号，将此SVN号之后修改的文件的时间更新(即比时间标记文件还更新，方便后期打包时挑出来)；(即图3、图4中B搭建编译目录的补丁分支)

9.4再编译需要编译的补丁模块，最后根据时间标记文件将所有新文件(包括编译好的程序)复制到临时目录，在临时目录中制作压缩包。(即图3、图4中E形成数据压缩包的补丁分支)

9.5统一发布工具根据压缩包、获取的SVN号制作成可执行的带安装行为的发布包，提交资源管理服务器。

此方法针对软件族群的功能特点，对问题提出了更高层的抽象，抽象出平台和应用，使得多产品间共性的问题统一解决，在此基础上的持续集成也利用此特性，进行“平台+应用”的多层次配合的持续集成，提高了软件开发的效率和正确率，缩短了开发的周期。

而本发明的范围不应局限于这些描述。任何在本发明原理范围内的修改、改进都属于本发明的保护范围。

Claims (7)

1.一种基于“平台+应用”模式的持续集成方法，其特征在于，所述持续集成方法包括以下步骤：

步骤1：首先在各软件产品的设计阶段进行统一规划，梳理软件需求，在架构上或功能上进行抽象，提取各产品共有功能或属性为平台，提取部分产品共有功能或属性为应用,并且在设计平台时增加支持二次开发的设计需求；

步骤2：建立资源服务器对以下资源进行集中管理：平台、应用的源代码、各产品的测试用例、配置文件、所用到的第三方组件或动态库、数据库定义、用于初始化工程的数据文件、产品搭建脚本、产品搭建运行环境的配置文件或安装脚本；

步骤3：将平台和各产品的各版本的发布包作为一种资源进行统一配置管理，以版本号、平台名称、产品名称、运行的操作系统名称为关键字，信息存储采用xml格式，并统一以web方式展现，在后续的产品持续集成中使用；

步骤4：定义产品包含哪些应用，基于哪个平台；编写平台、产品构建模板，包括编译打包脚本、发布包使用的安装脚本；定义各平台、产品的部署测试模板、测试用例，定义产品构建模板；

步骤5：使用统一发布工具，执行步骤4定义的平台构建模板自动执行软件集成，自动构建出特定版本号的各操作系统的平台安装发布包，并自动提交资源服务器统一管理，并自动采用邮件方式通知相关人员；

步骤6：执行步骤4定义的平台部署测试模板，对平台发布包进行单独的自动部署，进行自动测试；若测试发现缺陷，即为多产品共有缺陷，则修改平台代码、配置或第三方包，再返回步骤5进行迭代集成构建；

步骤7：开始产品的集成构建，使用统一发布工具，选择集成所使用的平台发布包版本号，执行步骤4中定义的产品构建模板来自动进行软件集成；

步骤8：进行产品软件自动部署测试，根据步骤4定义的产品部署测试模板，对各产品发布包进行单独的自动部署，自动测试，若发现缺陷，修改产品或平台的代码、配置，当修改的是产品的代码、配置，则修改后返回步骤7；当修改的是平台的代码、配置，则修改后返回步骤5进行迭代集成构建；

步骤9：集成构建产品补丁，以SVN修改记录、新编译结果文件来共同确定补丁中包含哪些文件，并在制作过程中采用了创建基准文件的方式来自动挑选确定补丁包中的内容。

2.根据权利要求1所述的基于“平台+应用”模式的持续集成方法，其特征在于：

在步骤1中，各产品共有功能或属性包括但不限于：需要开发的各自动化产品都必要的字符串通用操作库、基本统计函数库、监控基本处理流程库、通讯底层封装库、实时数据库、消息总线。

3.根据权利要求1或2所述的基于“平台+应用”模式的持续集成方法，其特征在于：

所述支持二次开发的设计需求包括但不限于二次开发接口。

4.根据权利要求1所述的基于“平台+应用”模式的持续集成方法，其特征在于：

在步骤2中，所述资源服务器支持网站查询浏览。

5.根据权利要求1所述的基于“平台+应用”模式的持续集成方法，其特征在于：

在步骤4中，编译打包脚本采用JavaScript语言来定义平台、产品的编译和打包制作的过程；安装脚本采用Lua语言定义各发布包的自动安装过程。

6.根据权利要求1所述的基于“平台+应用”模式的持续集成方法，其特征在于：

在步骤5中，通过平台构建模板自动执行软件集成的具体流程如下：

5.1从代码库SVN获取平台代码；

5.2从第三方库获取平台第三方资源压缩包并解压

5.3执行代码的编辑脚本；

5.4当是大版本制作时，根据配置选择相关文件进行压缩，并写入版本号、各SVN号信息；

5.5当是补丁制作时，选择比基准文件时间新的文件进行压缩，并写入版本号、各SVN号信息；

5.6制作自有格式的各操作系统上的软件安装包；

5.7软件安装包提交资源服务器，进行统一资源管理，并通过邮件方式通知相关人员。

7.根据权利要求1所述的基于“平台+应用”模式的持续集成方法，其特征在于：

在步骤7中，产品的集成构建流程如下：

7.1根据产品构建模板的打包脚本从资源服务器获取指定版本号的平台发布包，并解压平台但不执行安装脚本；

7.2从代码库SVN获取产品代码，所述产品代码包含多个SVN地址，包含多个应用代码；

7.3从第三方库获取产品第三方资源压缩包并解压；

7.4执行编辑脚本；

7.5当是大版本制作时，根据配置选择相关文件进行压缩，并写入版本号、各SVN号信息；

7.6当是补丁制作时，选择比基准文件时间新的文件进行压缩，并写入版本号、各SVN号信息；

7.7制作自有格式的各操作系统上的产品安装包；

7.8将产品安装包提交资源服务器进行统一管理，并通过邮件方式通知相关人员。

Images