CN111857722A - 一种基于三库模式的DevOps质量保障系统及方法 - Google Patents

Abstract

本发明涉及一种基于三库模式的DevOps质量保障系统及方法，属于计算机互联网技术领域，解决了现有技术中软件研发效率低、质量差且难以优化的问题。该系统包括Git‑dev模块，对代码进行集成并进行开发环境部署，以供自测，自测未通过，则将所述代码返回修改，直至自测通过；Git‑con模块，提取自测通过的所述代码并进行集成并进行测试环境部署，以供测试，测试未通过，则将代码返回修改或完善测试环境，直至测试通过；Git‑base模块，提取测试通过的代码并进行集成并进行生产环境部署，并将代码打包成程序包发布至生产环境中。该系统将软件的开发、测试及发布集于一体，能够快速定位软开发过程中的缺陷，易于软件优化，且提高了软件研发的效率和质量。

Description

一种基于三库模式的DevOps质量保障系统及方法

技术领域

本发明涉及计算机互联网技术领域，尤其涉及一种基于三库模式的DevOps质量保障系统。

背景技术

随着软件行业进入“互联网+”时代，市场对软件的产品和服务的交付提出了更高的要求。一方面，软件产品的开发需求变更频繁使迭代研发工作比重逐渐增大，造成软件版本发布部署次数增多。另一方面，软件架构过于庞大和复杂使手工部署的难度也明显上升。因此，在没有一套自动化的工具链的情况下，会带来大量重复性、易错的人工劳动。若存在线上运营系统的情况，频繁的发布部署又会给运维部门带来极大的压力，造就了开发和运维之间不可逾越的“城墙”。

但新技术和新研发工程实践的成熟为DevOps的产生和兴起提供了基础。例如以云计算(软件定义计算、存储、网络)为代表的灵活、弹性的基础设施供给能力；以微服务架构为代表的架构实践，为软件的持续交付降低了风险，提升了灵活性和交付效率；以Docker为代表的新的软件交付模式，简化了交付难度，且非常适合承载微服务架构下的软件交付；以敏捷开发为代表的研发工程实践已经达到了一定的成熟度，使得流式持续交付成为可能，但目前仍没有一套集软件开发、测试及发布与一体的系统。

现有技术至少存在以下缺陷，一是研发过程中，开发人员需要在各种开发工具之间频繁切换，复杂繁琐，大大降低了软件的研发效率；二是研发过程中，出现问题时，难以快速准确地定位问题，不仅降低了研发效率，而且难以对软件进行优化，降低了软件研发质量。

发明内容

鉴于上述的分析，本发明旨在提供一种基于三库模式的DevOps质量保障系统及方法，用以解决现有软件研发效率低、迭代发布慢、研发质量差、软件优化难的问题。

一方面，本发明提供了一种基于三库模式的DevOps质量保障系统，包括Git-dev模块、Git-con模块及Git-base模块；

所述Git-dev模块，用于对代码进行集成以获得第一程序包，对所述第一程序包进行开发环境部署，并存储于所述Git-dev模块的Dev-con介质库中，以供自测，自测未通过，则将所述代码返回修改，直至自测通过；

所述Git-con模块，用于提取自测通过的所述代码并进行集成以获得第二程序包，并对所述第二程序包进行测试环境部署，以供测试，测试未通过，则将所述代码返回修改或完善测试环境，直至测试通过；

所述Git-base模块，用于提取测试通过的所述代码并进行集成以获得第三程序包，对所述第三程序包进行生产环境部署，并将所述第三程序包发布至生产环境中。

进一步的，所述Git-dev模块包括：

第一代码检查单元，用于对所述代码依次进行静态检查、安全检查及质量检查，若不通过，则将所述代码返回修改；

第一编译构建单元，用于对代码检查通过后的所述代码进行编译构建及单元测试，然后打包成第一程序包；

第一测试检查单元，用于对所述第一程序包进行单元测试检查；

开发环境部署单元，用于对单元测试检查通过后的所述第一程序包进行开发环境部署，以供自测；

Dev-con介质库，用于存储所述第一程序包。

进一步的，所述Git-con模块包括：

第二代码检查单元，用于对自测通过的所述代码依次进行静态检查、安全检查及质量检查，若不通过，则返回修改代码；

第二编译构建单元，用于对代码检查通过后的所述代码进行编译构建及单元测试，然后打包成第二程序包；

第二测试检查单元，用于对所述第二程序包进行单元测试检查；

测试环境部署单元，用于对单元测试检查通过后的所述第二程序包进行测试环境部署，以供测试，并将部署后的所述第二程序包存储于所述Dev-con介质库中。

进一步的，所述第一代码检查单元和第二代码检查单元中的质量检查包括：

问题密度是否小于等于第一阈值、代码重复率是否小于等于第二阈值、圈复杂度是否小于等于第三阈值及认知复杂度是否小于等于第四阈值，若任一条件不满足，则质量检查不通过。

进一步的，所述第一测试检查单元和第二测试检查单元中的单元测试检查包括：

单元测试通过率是否大于等于第五阈值及单元测试覆盖率是否大于等于第六阈值，若任一条件不满足，则单元测试检查不通过。

进一步的，在所述Git-con模块中，若进行测试过程中涉及代码修改，则将修改后的代码返回至所述Git-dev模块中，并执行相应的流程。

进一步的，所述Git-base模块包括：

第三编译构建单元，用于对测试通过的所述代码进行编译构建获得第三程序包；

生产环境部署单元，用于对所述第三程序包进行生产环境部署，以供所述第三程序包的对外发布；

将部署后的所述第三程序包存储于base介质库中。

进一步的，所述开发环境部署单元、测试环境部署单元及生产环境部署单元，还用于分别自动为所述开发环境、测试环境及生产环境部署监控。

另一方面，本发明提供了一种基于三库模式的DevOps质量保障方法，利用前述的基于三库模式的DevOps质量保障系统，该方法包括：

步骤s1、对代码进行集成以获得第一程序包，对所述第一程序包进行开发环境部署，并存储于所述Git-dev模块的Dev-con介质库中，以供自测，自测未通过，则将所述代码返回修改，直至自测通过；

步骤s2、对自测通过的所述代码进行集成以获得第二程序包，并对所述第二程序包进行测试环境部署，以供测试，测试未通过，则将所述代码返回修改并再次执行步骤s1或完善测试环境，直至测试通过；

步骤s3、对测试通过的所述代码进行集成以获得第三程序包，对所述第三程序包进行生产环境部署，并将所述第三程序包发布至生产环境中；

所述集成包括代码检查及编译构建。

进一步的，所述对代码进行集成及开发环境部署包括：

步骤s11、对所述代码依次进行静态检查、安全检查及质量检查，若不通过，则返回修改代码；

步骤s12、对检查通过后的所述代码进行编译构建及单元测试，然后打包成第一程序包；

步骤s13、对所述第一程序包进行单元测试检查；

步骤s14、对单元测试检查通过后的所述第一程序包进行开发环境部署，以供自测，并将部署后的所述第一程序包存储于所述Dev-con介质库中；

所述对自测通过的所述代码进行集成及测试环境部署包括：

步骤s21、对自测通过的所述代码依次进行静态检查、安全检查及质量检查，若不通过，则返回修改代码；

步骤s22、对检查通过后的所述代码进行编译构建及单元测试，然后打包成第二程序包；

步骤s23、对所述第二程序包进行单元测试检查；

步骤s24、对单元测试检查通过后的所述第二程序包进行测试环境部署，以供测试，并将部署后的所述第二程序包存储于所述Dev-con介质库中；

所述对测试通过的所述代码进行集成及生产环境部署包括：

对测试通过的所述代码进行编译构建获得第三程序包；

对所述第三程序包进行生产环境部署，以供所述第三程序包的对外发布；以及

将部署后的所述第三程序包存储于base介质库中。

与现有技术相比，本发明至少可实现如下有益效果之一：

1、本发明提出的系统包括Git-dev模块、Git-con模块及Git-base模块，即集软件开发、测试及发布于一体的自动化软件发布系统，在各流程中能够自动实现代码的检查、编译构建或环境部署，规避了开发人员频繁切换各种工具进行繁琐复杂的工作的缺陷，并且可以有效保证软件生产环境与软件源代码同步，提高了软件开发、测试及发布的效率。

2、本发明通过对软件的开发环境、测试环境及生产环境进行实时监控，以供开发人员和维护人员在软件开发、测试和发布的过程中快速准确地定位异常，可以有效提升开发人员的开发效率和质量及运维人员的运维效率和质量。

3、本发明在软件测试过程中，若涉及代码修改，会将修改后的代码重新返回至代码开发流程，并作为升级版本进行代码存储及管理，以供开发人员在后续相关软件开发或软件应用时进行调用。

本发明中，上述各技术方案之间还可以相互组合，以实现更多的优选组合方案。本发明的其他特征和优点将在随后的说明书中阐述，并且，部分优点可从说明书中变得显而易见，或者通过实施本发明而了解。本发明的目的和其他优点可通过说明书以及附图中所特别指出的内容中来实现和获得。

附图说明

附图仅用于示出具体实施例的目的，而并不认为是对本发明的限制，在整个附图中，相同的参考符号表示相同的部件。

图1为本发明实施例基于三库模式的DevOps质量保障系统的示意图；

图2为本发明实施例基于三库模式的DevOps质量保障方法的流程图；

图3为本发明实施例基于三库模式的DevOps质量保障的过程的示意图。

具体实施方式

下面结合附图来具体描述本发明的优选实施例，其中，附图构成本申请一部分，并与本发明的实施例一起用于阐释本发明的原理，并非用于限定本发明的范围。

系统实施例

本发明的一个具体实施例，公开了一种基于三库模式的DevOps质量保障系统。如图1所示，该系统包括Git-dev模块、Git-con模块及Git-base模块。

其中，开发人员将编写好的代码交付至Git-dev模块，该Git-dev模块对代码进行集成以获得第一程序包，对第一程序包进行开发环境部署，并存储于该Git-dev模块的Dev-con介质库中，以供开发人员自测。

具体的，即检测该第一程序包在部署的开发环境中是否能够正常运行，若运行正常，则自测通过；若出现异常，自测未通过，则将所述代码返回给开发人员进行代码修改，直至自测通过。优选的，将修改的代码自动更新至第一程序包中，并为其标注相应的版本号。

自测通过后，Git-con模块利用git插件提取自测通过的代码并进行集成以获得第二程序包，并对第二程序包进行测试环境部署，以供测试。具体的，即测试第二程序包在部署的测试环境中是否能够正常运行，若运行正常，则测试通过；若出现异常，则测试不通过，则将所述代码返回修改或完善测试环境，直至测试通过。为测试通过的第二程序包标注对应的版本号并存储于Dev-con介质库中。

优选的，若在测试过程中涉及代码修改，则将修改后的代码返回至Git-dev模块，并再次执行相应的流程，同时，为基于修改后的代码获得的新的第一程序包标注新的版本号，并存储于Dev-con介质库中，对应的为获得的新的第二程序包标注新的版本号并存储于Dev-con介质库中。

测试通过后，Git-base模块利用git插件提取测试通过的代码并进行集成以获得第三程序包，对第三程序包进行生产环境部署，并将第三程序包发布至生产环境中，以供用户应用。

具体的，对代码进行集成包括对代码进行代码检查及编译构建。

优选的，开发人员进行软件更新、开发相关联的软件或软件应用时可以直接从介质库中调用对应版本号的程序包。

优选的，Git-dev模块包括：

第一代码检查单元，用于对代码依次进行静态检查、安全检查及质量检查，若质量检查不通过，则将代码返回至开发人员进行修改。

第一编译构建单元，用于对代码检查通过后的代码进行编译构建及单元测试，然后打包成第一程序包。

第一测试检查单元，用于对第一程序包进行单元测试检查。

开发环境部署单元，用于对单元测试检查通过后的第一程序包进行开发环境部署，以供开发人员进行自测。

Dev-con介质库，用于存储所述第一程序包。

优选的，Git-con模块包括：

第二代码检查单元，用于对自测通过的代码依次进行静态检查、安全检查及质量检查，若不通过，则返回修改代码。

第二编译构建单元，用于对代码检查通过后的代码进行编译构建及单元测试，然后打包成第二程序包。

第二测试检查单元，用于对第二程序包进行单元测试检查。

测试环境部署单元，用于对单元测试检查通过后的第二程序包进行测试环境部署，以供测试。并将部署后的第二程序包存储于Dev-con介质库中。

优选的，Git-base模块包括：

第三编译构建单元，用于对测试通过的代码进行编译构建获得第三程序包，优选的在对代码进行编译构建之后还可以对代码进行单元测试以获得第三程序包。

生产环境部署单元，用于对第三程序包进行生产环境部署，以供第三程序包的对外发布。

将部署后的第三程序包存储于base介质库中。

优选的，Git-base模块还可以包括代码检查单元及测试检查单元，对测试通过的代码依次进行静态检查、安全检查及质量检查，若不通过，则返回修改代码；以及对第三程序包进行单元测试检查。

优选的，在Git-dev模块、Git-con模块及Git-base模块中，代码检查单元通过扫描的方式扫描代码，并进行静态检查及安全检查，具体的，检查代码是否符合标准规范、是否出现代码编辑错误、是否存在代码重复以及检查代码的可测试性和可维护性等。具体的，通过检查代码的控制流语句确定代码的可测试性，通过检查代码中的语法糖、控制流语句的中断及代码的嵌套结构确定代码的可维护性，其中，代码的可测试性及可维护性均通过具体的数字表示。

优选的，可以根据软件开发需求，在代码检查单元为不同类型的代码创建不同的检查任务，或为同一代码配置相应的检查范围，或在不同的模块中为代码创建不同的检查任务。优选的，第一代码检查单元和第二代码检查单元还可以对不同语言的代码进行静态检查及安全检查。

然后，基于静态检查和安全检查结果进行代码质量检查，具体包括，基于检查出的编辑错误数量判定问题密度是否小于等于第一阈值、基于检查出的代码重复数量判定代码重复率是否小于等于第二阈值、基于确定的代码可测试性判定圈复杂度是否小于等于第三阈值及基于确定的代码可维护性判定认知复杂度是否小于等于第四阈值，若任一条件不满足，则质量检查不通过。优选的，代码检查单元还可以根据质量检查结果自动生成代码质量分析报告及缺陷改进意见，以供开发人员快速定位代码缺陷并进行修改。

优选的，分别为Git-dev模块、Git-con模块及Git-base模块配置构建服务器，并根据软件开发需求对应地为其编译构建单元创建编译构建任务，编译构建单元通过执行相应的编译构建任务自动实现代码的获取、构建、打包及单元测试。

具体的，单元测试部分主要是针对代码的逻辑性进行的测试，示例性的，通过编写测试代码并执行相应的测试代码对软件代码进行逻辑性测试。

优选的，第一测试检查单元和第二测试检查单元及Git-base模块中的单元测试检查包括：

单元测试通过率是否大于等于第五阈值及单元测试覆盖率是否大于等于第六阈值，若任一条件不满足，则单元测试检查不通过。

具体的，可以根据软件开发需求对第一阈值、第二阈值、第三阈值、第四阈值、第五阈值及第六阈值进行设置。

优选的，Git-dev模块、Git-con模块及Git-base模块中的环境部署单元通过执行对应的编排文件实现开发环境、测试环境及生产环境的可视化、自动化部署。

具体的，可以基于统一的编排文件模板，根据软件开发需求、测试需求及发布需求自定义编辑或调整编排文件。

优选的，所述开发环境部署单元、测试环境部署单元及生产环境部署单元，还用于分别自动为软件开发环境、测试环境及生产环境部署监控。

具体的，部署的监控可以在开发人员进行自测，测试人员进行测试及软件发布的过程中，分别自动监控第一程序包、第二程序包及第三程序包(即发布的软件)的运行，以及时发现并定位异常。若定位是软件代码的第几行出现错误，软件开发人员可以根据监控发现的异常信息及时对代码进行修改，若定位是开发环境、测试环境或生产环境(即发布环境)所依赖的外部硬件设备出现异常，则运维人员可以根据监控发现的异常信息技术对外部硬件设备进行维修或更换，以保证软件正常运行。

方法实施例

本发明的另一个实施例，公开了一种基于三库模式的DevOps质量保障方法，利用前述的基于三库模式的DevOps质量保障系统。如图2所示，该方法包括：

步骤s1、对代码进行集成以获得第一程序包，对第一程序包进行开发环境部署，并存储于Git-dev模块的Dev-con介质库中，以供自测，自测未通过，则将代码返回修改，直至自测通过。

步骤s2、对自测通过的代码进行集成以获得第二程序包，并对第二程序包进行测试环境部署，以供测试，测试未通过，则将代码返回修改并再次执行步骤s1或完善测试环境，直至测试通过。

步骤s3、对测试通过的代码进行集成以获得第三程序包，对第三程序包进行生产环境部署，并将第三程序包发布至生产环境中，以供用户使用。

其中，所述集成包括代码检查及编译构建。

具体的，基于三库模式的DevOps质量保障的过程如图3所示。

优选的，步骤s1、对代码进行集成及开发环境部署包括：

步骤s11、对代码依次进行静态检查、安全检查及质量检查，若不通过，则返回修改代码。

步骤s12、对检查通过后的代码进行编译构建及单元测试，然后打包成第一程序包。

步骤s13、对第一程序包进行单元测试检查。

步骤s14、对单元测试检查通过后的第一程序包进行开发环境部署，以供自测，并将部署后的第一程序包存储于Dev-con介质库中。

具体的，步骤s2、对自测通过的代码进行集成及测试环境部署包括：

步骤s21、对自测通过的代码依次进行静态检查、安全检查及质量检查，若不通过，则返回修改代码。

步骤s22、对检查通过后的代码进行编译构建及单元测试，然后打包成第二程序包。

步骤s23、对第二程序包进行单元测试检查。

步骤s24、对单元测试检查通过后的第二程序包进行测试环境部署，以供测试，并将部署后的第二程序包存储于所述Dev-con介质库中。

具体的，步骤s3、对测试通过的代码进行集成及生产环境部署包括：

对测试通过的代码进行编译构建获得第三程序包。

对第三程序包进行生产环境部署，以供第三程序包的对外发布。

以及将部署后的第三程序包存储于base介质库中。

优选的，步骤s3中还可以包括代码检查单元及测试检查单元，对测试通过的代码依次进行静态检查、安全检查及质量检查，若不通过，则返回修改代码；以及对第三程序包进行单元测试检查。

优选的，代码检查通过扫描的方式扫描代码，并进行静态检查及安全检查，具体的，检查代码是否符合标准规范、是否出现代码编辑错误、是否存在代码重复等。优选的，可以根据软件开发需求，在代码检查单元为不同类型的代码创建不同的检查任务，或为同一代码配置相应的检查范围，或在软件开发、软件测试及软件发布过程中为代码创建不同的检查任务。优选的，可以对不同语言的代码进行静态检查及安全检查。

然后，基于静态检查和质量检查结果进行代码质量检查，具体包括，问题密度是否小于等于第一阈值、代码重复率是否小于等于第二阈值、圈复杂度是否小于等于第三阈值及认知复杂度是否小于等于第四阈值，若任一条件不满足，则质量检查不通过。优选的，还可以根据质量检查结果自动生成代码质量分析报告及缺陷改进意见，以供开发人员快速定位代码缺陷并进行修改。

优选的，在软件开发、软件测试及软件发布的过程中通过执行相应的编译构建任务自动实现代码的获取、构建、打包及单元测试。

具体的，单元测试部分主要是针对代码的逻辑性进行的测试，示例性的，通过编写测试代码并执行相应的测试代码对软件代码进行逻辑性测试。

优选的，单元测试检查包括：

单元测试通过率是否大于等于第五阈值及单元测试覆盖率是否大于等于第六阈值，若任一条件不满足，则单元测试检查不通过。

具体的，可以根据软件开发需求对第一阈值、第二阈值、第三阈值、第四阈值、第五阈值及第六阈值进行设置。

优选的，通过执行相应的编排文件实现开发环境、测试环境及生产环境的可视化、自动化部署。

具体的，可以基于统一的编排文件模板，根据软件开发需求、测试需求及发布需求自定义编辑或调整编排文件。

优选的，还包括分别自动为软件开发环境、测试环境及生产环境部署监控。

具体的，部署的监控可以在开发人员进行自测，测试人员进行测试及软件发布的过程中，分别自动监控第一程序包、第二程序包及第三程序包(即发布的软件)的运行，以及时发现并定位异常。若定位是软件代码的第几行出现错误，软件开发人员可以根据监控发现的异常信息及时对代码进行修改，若定位是开发环境、测试环境或生产环境(即发布环境)所依赖的外部硬件设备出现异常，则运维人员可以根据监控发现的异常信息技术对外部硬件设备进行维修或更换，以保证软件正常运行。

与现有技术相比，本发明提出的基于三库模式的DevOps质量保障系统及方法，首先，该系统包括Git-dev模块、Git-con模块及Git-base模块，即集软件开发、测试及发布于一体的自动化软件发布系统，在各流程中能够自动实现代码的检查、编译构建或环境部署，规避了开发人员频繁切换各种工具进行繁琐复杂的工作的缺陷，并且可以有效保证软件生产环境与软件源代码同步，提高了软件开发、测试及发布的效率；其次，本发明通过对软件的开发环境、测试环境及生产环境进行实时监控，以供开发人员和维护人员在软件开发、测试和发布的过程中快速准确地定位异常，可以有效提升开发人员的开发效率和质量及运维人员的运维效率和质量；最后，本发明在软件测试过程中，若涉及代码修改，会将修改后的代码重新返回至代码开发流程，并作为升级版本进行代码存储及管理，以供开发人员在后续相关软件开发或软件应用时进行调用。

本领域技术人员可以理解，实现上述实施例方法的全部或部分流程，可以通过计算机程序来指令相关的硬件来完成，所述的程序可存储于计算机可读存储介质中。其中，所述计算机可读存储介质为磁盘、光盘、只读存储记忆体或随机存储记忆体等。

以上所述，仅为本发明较佳的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到的变化或替换，都应涵盖在本发明的保护范围之内。

Claims (10)

1.一种基于三库模式的DevOps质量保障系统，其特征在于，包括Git-dev模块、Git-con模块及Git-base模块；

所述Git-dev模块，用于对代码进行集成以获得第一程序包，对所述第一程序包进行开发环境部署，并存储于所述Git-dev模块的Dev-con介质库中，以供自测，自测未通过，则将所述代码返回修改，直至自测通过；

所述Git-con模块，用于提取自测通过的所述代码并进行集成以获得第二程序包，并对所述第二程序包进行测试环境部署，以供测试，测试未通过，则将所述代码返回修改或完善测试环境，直至测试通过；

所述Git-base模块，用于提取测试通过的所述代码并进行集成以获得第三程序包，对所述第三程序包进行生产环境部署，并将所述第三程序包发布至生产环境中。

2.根据权利要求1所述的DevOps质量保障系统，其特征在于，所述Git-dev模块包括：

第一代码检查单元，用于对所述代码依次进行静态检查、安全检查及质量检查，若不通过，则将所述代码返回修改；

第一编译构建单元，用于对代码检查通过后的所述代码进行编译构建及单元测试，然后打包成第一程序包；

第一测试检查单元，用于对所述第一程序包进行单元测试检查；

开发环境部署单元，用于对单元测试检查通过后的所述第一程序包进行开发环境部署，以供自测；

Dev-con介质库，用于存储所述第一程序包。

3.根据权利要求2所述的DevOps质量保障系统，其特征在于，所述Git-con模块包括：

第二代码检查单元，用于对自测通过的所述代码依次进行静态检查、安全检查及质量检查，若不通过，则返回修改代码；

第二编译构建单元，用于对代码检查通过后的所述代码进行编译构建及单元测试，然后打包成第二程序包；

第二测试检查单元，用于对所述第二程序包进行单元测试检查；

测试环境部署单元，用于对单元测试检查通过后的所述第二程序包进行测试环境部署，以供测试，并将部署后的所述第二程序包存储于所述Dev-con介质库中。

4.根据权利要求3所述的DevOps质量保障系统，其特征在于，所述第一代码检查单元和第二代码检查单元中的质量检查包括：

问题密度是否小于等于第一阈值、代码重复率是否小于等于第二阈值、圈复杂度是否小于等于第三阈值及认知复杂度是否小于等于第四阈值，若任一条件不满足，则质量检查不通过。

5.根据权利要求3所述的DevOps质量保障系统，其特征在于，所述第一测试检查单元和第二测试检查单元中的单元测试检查包括：

单元测试通过率是否大于等于第五阈值及单元测试覆盖率是否大于等于第六阈值，若任一条件不满足，则单元测试检查不通过。

6.根据权利要求3所述的DevOps质量保障系统，其特征在于，在所述Git-con模块中，若进行测试过程中涉及代码修改，则将修改后的代码返回至所述Git-dev模块中，并执行相应的流程。

7.根据权利要求3所述的DevOps质量保障系统，其特征在于，所述Git-base模块包括：

第三编译构建单元，用于对测试通过的所述代码进行编译构建获得第三程序包；

生产环境部署单元，用于对所述第三程序包进行生产环境部署，以供所述第三程序包的对外发布；以及

将部署后的所述第三程序包存储于base介质库中。

8.根据权利要求1所述的DevOps质量保障系统，其特征在于，所述开发环境部署单元、测试环境部署单元及生产环境部署单元，还用于分别自动为所述开发环境、测试环境及生产环境部署监控。

9.一种基于三库模式的DevOps质量保障方法，利用权利要求1-8任一项所述的基于三库模式的DevOps质量保障系统，其特征在于，包括：

步骤s1、对代码进行集成以获得第一程序包，对所述第一程序包进行开发环境部署，并存储于所述Git-dev模块的Dev-con介质库中，以供自测，自测未通过，则将所述代码返回修改，直至自测通过；

步骤s2、对自测通过的所述代码进行集成以获得第二程序包，并对所述第二程序包进行测试环境部署，以供测试，测试未通过，则将所述代码返回修改并再次执行步骤s1或完善测试环境，直至测试通过；

步骤s3、对测试通过的所述代码进行集成以获得第三程序包，对所述第三程序包进行生产环境部署，并将所述第三程序包发布至生产环境中；

所述集成包括代码检查及编译构建。

10.根据权利要求9所述的DevOps质量保障方法，其特征在于，所述对代码进行集成及开发环境部署包括：

步骤s11、对所述代码依次进行静态检查、安全检查及质量检查，若不通过，则返回修改代码；

步骤s12、对检查通过后的所述代码进行编译构建及单元测试，然后打包成第一程序包；

步骤s13、对所述第一程序包进行单元测试检查；

步骤s14、对单元测试检查通过后的所述第一程序包进行开发环境部署，以供自测，并将部署后的所述第一程序包存储于所述Dev-con介质库中；

所述对自测通过的所述代码进行集成及测试环境部署包括：

步骤s21、对自测通过的所述代码依次进行静态检查、安全检查及质量检查，若不通过，则返回修改代码；

步骤s22、对检查通过后的所述代码进行编译构建及单元测试，然后打包成第二程序包；

步骤s23、对所述第二程序包进行单元测试检查；

步骤s24、对单元测试检查通过后的所述第二程序包进行测试环境部署，以供测试，并将部署后的所述第二程序包存储于所述Dev-con介质库中；

所述对测试通过的所述代码进行集成及生产环境部署包括：

对测试通过的所述代码进行编译构建获得第三程序包；

对所述第三程序包进行生产环境部署，以供所述第三程序包的对外发布；以及

将部署后的所述第三程序包存储于base介质库中。

Images