技术领域
[0001] 本
发明涉及自动化运维，更具体地说是指基于自动化运维的持续集成流水线系统及其方法。
背景技术
[0002] 在过去的几十年里，为了按时交付
软件产品和服务，越来越多的“互联网+运营商”企业意识到，对于传统把开发和运营割裂开的做法，不适合现代产品和服务开发和运营的需求。于是，把开发和运营作为整体来看待的DevOps技术思想逐步深入人心，随之也逐步有了对DevOps系统的需求，希望能有工具来统一支持开发和运营的交付工作及之后的环境管理工作，即需要一系列的持续集成，持续交付，自动化部署，自动化测试监控，以提升开发测试运营过程中的部署效率，简化开发测试运维过程的管理，降低交付
风险，降低沟通成本及运营成本，DevOps(英文Development和Operations的组合)是一组过程、方法与系统的统称，用于促进开发(应用程序/
软件工程)、技术运营和
质量保障(QA)部
门之间的沟通、协作与整合。它的出现是由于软件行业日益清晰地认识到：为了按时交付软件产品和服务，开发和运营工作必须紧密合作。
[0003] 很多“互联网+运营商”企业已经意识到或者做到了从流程上规范应用上线的审批环节、各个
角色之间的配合关系并
固化在流程平台之中，以架起开发方与运维方之间的沟通
桥梁，但是大部分仍停留在理念和流程层面，缺乏将上线持续集成的过程标准化与自动化的技术手段，无法提升应用质量，且企业管理上的成本无法降低。
[0004] 因此，有必要设计一种基于自动化运维的持续集成流水线系统，实现应用DEVOPS理念，通过技术平台标准化、自动化的执行和落实持续集成，提升应用质量，降低企业管理成本。
发明内容
[0005] 本发明的目的在于克服
现有技术的
缺陷，提供基于自动化运维的持续集成流水线系统及其方法。
[0006] 为实现上述目的，本发明采用以下技术方案：基于自动化运维的持续集成流水线系统，包括自动化运维单元、版本控制单元、版本发布管理单元、项目管理单元、代码质量管理单元以及配置单元；
[0007] 所述版本控制单元，用于采用分布式版本库的方式控制发布的应用版本；
[0008] 所述版本发布管理单元，用于监控持续进行的应用版本发布工作；
[0009] 所述项目管理单元，用于控制和管理应用版本的发布过程；
[0010] 所述代码质量管理单元，用于全面自动化分析和管理应用程序的代码质量；
[0011] 所述配置单元，用于在应用新版本开发测试完成后，对环境的自动配置和控制以及进行应用的自动配置；
[0012] 所述自动化运维单元，用于集成所述版本控制单元、版本发布管理单元、项目管理单元、代码质量管理单元以及配置单元，且将所述版本控制单元、版本发布管理单元、项目管理单元、代码质量管理单元以及配置单元作为调用
接口，供用户调用。
[0013] 其进一步技术方案为：所述系统还包括FTP
服务器；所述FTP服务器，用于存储所述版本发布管理单元以及项目管理单元处理后的结果，且与所述配置单元进行系统测试、验收测试以及应用的上线发布，获取检查结果输入至所述代码质量管理单元中。
[0014] 本发明还提供了基于自动化运维的持续集成流水线的方法，所述方法包括：
[0015] 通过版本控制单元获取应用代码中的目标表记录以及原数据表记录，更新目标表中的记录；
[0016] 执行自动化的软件构建过程，并进行单元测试，获取二进制包；
[0017] 将二进制包存储于FTP服务器中；
[0018] 通过配置单元配置环境；
[0019] 部署二进制包；
[0020] 分别对应用进行系统测试、验收测试以及上限发布测试，获取测试后的检查结果；
[0021] 将所述检查结果发送至代码质量管理单元，进行代码质量管理和分析。
[0022] 其进一步技术方案为：通过版本控制单元获取应用代码中的目标表记录以及原数据表记录，更新目标表中的记录的步骤，包括以下具体步骤：
[0023] 获取目标表记录以及原数据表记录；
[0024] 检测目标表记录与原数据表记录的一致性，当记录在原数据表和目标表中均存在，被原数据表中的记录更新目标表中的记录，当记录在目标表中不存在而在原数据表中存在，原数据表的对应记录将被插入到目标表中。
[0025] 其进一步技术方案为：执行自动化的软件构建过程，并进行单元测试，获取二进制包的步骤，包括以下具体步骤：
[0026] 对代码进行代码分析以及编译；
[0027] 对代码的单元或特性进行测试；
[0028] 对测试后的代码进行组装打包，形成二进制包。
[0029] 其进一步技术方案为：通过配置单元配置环境的步骤，包括以下具体步骤：
[0030] 复制生产环境中的程序和数据到本地的测试环境中；
[0031] 根据设定的上线部署步骤进行自动化部署；
[0032] 对上线步骤进行验证，判断所述上线步骤是否有问题；
[0033] 若是，则
修改上线部署步骤，并进入下一步骤，若无，则进入下一步骤；
[0034] 根据设定的上线部署步骤，配置统一的生产环境部署步骤，自动化配置生产环境。
[0035] 其进一步技术方案为：分别对应用进行系统测试、验收测试以及上限发布测试，获取测试后的检查结果的步骤，包括以下具体步骤：
[0036] 对应用的环境进行冒烟测试；
[0037] 对测试系统的可执行性以及连接系统交互的互通性进行测试；
[0038] 对应用的预生产环境进行冒烟测试以及验收测试；
[0039] 对应用的生产环境进行冒烟测试。
[0040] 其进一步技术方案为：将所述检查结果发送至代码质量管理单元，进行代码质量管理和分析的步骤，包括以下具体步骤：
[0042] 利用插件对所述检查结果进行再加工处理，获取加工结果；
[0043] 通过量化的方式度量加工结果，获取代码质量的变化程度。
[0044] 本发明与现有技术相比的有益效果是：本发明的基于自动化运维的持续集成流水线系统，通过在自动化运维单元上集成版本控制单元、版本发布管理单元、项目管理单元、代码质量管理单元以及配置单元，从版本控制、
环境控制以及测试控制三个方面对应用的上线过程进行自动化优化，形成上线持续集成流水线，提高上线效率，实现持续集成流水线，应用DEVOPS理念，通过技术平台标准化、自动化的执行和落实持续集成，提升应用质量，降低企业管理成本。
[0045] 下面结合
附图和具体
实施例对本发明作进一步描述。
附图说明
[0046] 图1为本发明具体实施例提供的基于自动化运维的持续集成流水线系统的结构
框图；
[0047] 图2为本发明具体实施例提供的基于自动化运维的持续集成流水线的方法的
流程图；
[0048] 图3为本发明具体实施例提供的更新目标表中的记录的流程图；
[0049] 图4为本发明具体实施例提供的获取二进制包的流程图；
[0050] 图5为本发明具体实施例提供的通过配置单元配置环境的流程图；
[0051] 图6为本发明具体实施例提供的获取测试后的检查结果的流程图；
[0052] 图7为本发明具体实施例提供的代码质量管理和分析的流程图；
[0053] 图8为本发明具体实施例提供的基于自动化运维的持续集成流水线的方法的
框架图。
具体实施方式
[0054] 为了更充分理解本发明的技术内容，下面结合具体实施例对本发明的技术方案进一步介绍和说明，但不局限于此。
[0055] 如图1～8所示的具体实施例，本实施例提供的基于自动化运维的持续集成流水线系统，可以运用在应用上线的持续集成流水线过程中，实现应用DEVOPS理念，通过技术平台标准化、自动化的执行和落实持续集成，提升应用质量，降低企业管理成本。
[0056] 如图1所示，本实施例提供了基于自动化运维的持续集成流水线系统，其包括自动化运维单元1、版本控制单元2、版本发布管理单元3、项目管理单元4、代码质量管理单元5以及配置单元6。
[0057] 版本控制单元2，用于采用分布式版本库的方式控制发布的应用版本。
[0058] 版本发布管理单元3，用于监控持续进行的应用版本发布工作。
[0059] 项目管理单元4，用于控制和管理应用版本的发布过程。
[0060] 代码质量管理单元5，用于全面自动化分析和管理应用程序的代码质量。
[0061] 配置单元6，用于在应用新版本开发测试完成后，对环境的自动配置和控制以及进行应用的自动配置。
[0062] 自动化运维单元1，用于集成所述版本控制单元2、版本发布管理单元3、项目管理单元4、代码质量管理单元5以及配置单元6，且将所述版本控制单元2、版本发布管理单元3、项目管理单元4、代码质量管理单元5以及配置单元6作为调用接口，供用户调用。
[0063] 另外，上述的版本控制单元2具体是采用GIT工具完成，将Git作为发布程序的版本控制工具，GIT采用了分布式版本库的方式，使源代码的发布和交流极其方便，而且Git的速度很快，这对于互联网公司频繁的发布来说很重要，Git最为出色的是它的合并
跟踪(merge tracing)能
力，很多传统的项目版本库一直都是只有一个分支主人，在Git版本库中创建分支的成本几乎为零，所以多创建几个分支，也不会造成成本的增加，有利于更清晰的展现是不同环境下跟版本之间的对应关系和变化过程。
[0064] 上述的版本发布管理单元3具体是采用Jenkins工具实现的，将Jenkins作为持续的软件版本发布管理工具，由其对持续进行的发布工作进行监控，Jenkins本身是免费的，可以降低工具使用的成本；同时Jenkins支持多种平台(windows、linux、os x都支持)，便于适应不同的发布环境；使用很便捷，不仅安装、配置简单，而且可以使用其Web
可视化管理界面，调用里面丰富的tips帮助信息。
[0065] 应用发布工作具有明确的发布的目的、时间要求、质量要求和成本要求，所以发布本身就具备项目的属性，上述的项目管理单元4采用的是Maven这样的项目管理工具，其对复杂的应用发布以及多个应用发布进行管理，它包含了一个项目对象模型、一组标准集合、一个项目生命周期、一个依赖管理系统和用来运行定义在生命周期阶段中插件目标的逻辑，当使用Maven的时候，用一个明确定义的发布过程模型来描述发布，Maven可以应用横切的逻辑展现整个发布的过程以便于控制和管理。
[0066] 为了支持快速变化的业务要求，则要提供高质量低成本的管理程序代码，及时对代码质量进行分析并给出合理的解决方案，上述的代码质量管理单元5具体是采用Sonar工具，Sonar是一个开源的代码质量管理系统，支持超过25种语言，可以与版本发布管理单元3Jenkins、Eclipse和JIRA等其他外部工具集成，从而实现对代码的质量的全面自动化分析和管理，将Sonar作为代码的质量管理平台，对传统的代码静态检测如PMD、FindBugs等工具进行整合。
[0067] 将Sonar与Maven、Jenkins通过saltstack集成、进行统一配置。
[0068] 上述的自动化运维单元1具体是Saltstack，将Saltstack作为整个系统的一个整体平台框架，而不仅仅是一个操作性工具，基于设计的各单元以及对应API，在Salt上进行二次开发，将salt跟现有的运维系统结合，通过Saltstack将各个独立的单元构集成在一起，这些单元都可以当做Saltstack的API，然后在上层做
基础开发可以通过调用Saltstack的API模
块进行，通过在python中import引入对应的API模块实现要实现的功能即可，然后写自己对应的需求代码，实现不同应用。从应用发布工作本身来看，提高在基础架构环境下各种软件平台兼容能力、工作的契合度、以及应用部署和发布的频次和效率，有助于提升应用质量，有助于支持业务以更好的吸纳更多的用户，除此之外，就对开发与运维部门间合作能力和沟通效率有提升作用、降低了管理上的成本。
[0069] 更进一步的，上述的系统还包括FTP服务器7；FTP服务器7，用于存储所述版本发布管理单元3以及项目管理单元4处理后的结果，且与所述配置单元6进行系统测试、验收测试以及应用的上线发布，获取检查结果输入至所述代码质量管理单元5中。
[0070] 上述的API是一些预先定义的函数，目的是提供应用程序与开发人员基于某软件或
硬件得以
访问一组例程的能力，而又无需访问源码，或理解内部工作机制的细节。
[0071] 上述的基于自动化运维的持续集成流水线系统，通过在自动化运维单元1上集成版本控制单元2、版本发布管理单元3、项目管理单元4、代码质量管理单元5以及配置单元6，从版本控制、环境控制以及测试控制三个方面对应用的上线过程进行自动化优化，形成上线持续集成流水线，提高上线效率，实现持续集成流水线，应用DEVOPS理念，通过技术平台标准化、自动化的执行和落实持续集成，提升应用质量，降低企业管理成本。
[0072] 如图2所示，本实施例还提供了基于自动化运维的持续集成流水线方法，该方法包括：
[0073] S1、通过版本控制单元2获取应用代码中的目标表记录以及原数据表记录，更新目标表中的记录；
[0074] S2、执行自动化的软件构建过程，并进行单元测试，获取二进制包；
[0075] S3、将二进制包存储于FTP服务器7中；
[0076] S4、通过配置单元6配置环境；
[0077] S5、部署二进制包；
[0078] S6、分别对应用进行系统测试、验收测试以及上限发布测试，获取测试后的检查结果；
[0079] S7、将所述检查结果发送至代码质量管理单元5，进行代码质量管理和分析。
[0080] 对于上述的S1步骤，通过版本控制单元2获取应用代码中的目标表记录以及原数据表记录，更新目标表中的记录的步骤，包括以下具体步骤：
[0081] S11、获取目标表记录以及原数据表记录；
[0082] S12、检测目标表记录与原数据表记录的一致性，当记录在原数据表和目标表中均存在，被原数据表中的记录更新目标表中的记录，当记录在目标表中不存在而在原数据表中存在，原数据表的对应记录将被插入到目标表中。
[0083] 分布管理必然导致大量的分支和合并操作。在传统的CVS里面制作分支和合并简直效率较低，可以采用版本控制系统作为一个用于替代CVS的系统，专门改进分支操作，同时要考虑有效合并，如果不能很方便地合并回溯，做分支依然会混乱，因此，有必要检查原数据表记录和目标表记录，如果记录在原数据表和目标表中均存在，则目标表中的记录应被原数据表中的记录所更新；如果目标表中不存在的相应记录而在原数据表中存在，则原数据表的对应记录将被插入到目标表中，这样可以将程序文件集中放置在FTP服务器7之中，进行
软件包的上传和拉取的授权控制、版本控制与变更控制，以确保各个环境下所用版本是一致的，也便于合并回溯。
[0084] 上述的CVS系统是一个C/S系统，是一个常用的代码版本控制软件，主要在开源软件管理中使用。
[0085] 更进一步的，对于上述的S2步骤，执行自动化的软件构建过程，并进行单元测试，获取二进制包的步骤，包括以下具体步骤：
[0086] S21、对代码进行代码分析以及编译；
[0087] S22、对代码的单元或特性进行测试；
[0088] S23、对测试后的代码进行组装打包，形成二进制包。
[0089] 上述的S2步骤具体是由版本发布管理单元3和项目管理单元4完成，单元测试是在开发工作完成的基础上，执行一个自动化的软件构建过程，包括编译、打包、测试、部署等环节，这个过程重点关注软件构建和单元/特性测试、代码质量，本阶段的关键任务为自动化测试的基础也即单元测试
覆盖，在一个不依赖于其他系统的类中，通过单元测试来测试独立的单元。
[0090] 对于上述的S3步骤，将二进制包存储于FTP服务器7，是为了供测试调取二进制包，进行软件包的上传和拉取的授权控制、版本控制与变更控制，以确保各个环境下所用版本是一致的。
[0091] 更进一步地，对于上述的S4步骤，通过配置单元6配置环境的步骤，包括以下具体步骤：
[0092] S41、复制生产环境中的程序和数据到本地的测试环境中；
[0093] S42、根据设定的上线部署步骤进行自动化部署；
[0094] S43、对上线步骤进行验证，判断所述上线步骤是否有问题；
[0095] 若是，则S44、修改上线部署步骤，并进入下一步骤，若无，则进入下一步骤；
[0096] S45、根据设定的上线部署步骤，配置统一的生产环境部署步骤，自动化配置生产环境。
[0097] 当应用新版本开发测试完成后，可由开发团队的成员登录运维平台，填写发布
申请单，申请单的内容应包括选择新版本的上线部署步骤(即设定的上线部署步骤)，测试人员为了保证能够升级部署成功，首先要复制生产环境中的程序和数据到本地的测试环境中，然后根据上线申请单中所描述的上线部署步骤进行自动化部署，对上线步骤进行验证。如果发现上线部署步骤有问题，如生产环境的路径与上线部署步骤中描述的不一致等，则应与开发人员进行沟通，进行修改上线部署步骤，开发人员修改后，再次通知测试人员和运维人员查看并确认，确认无误后，运维人员根据部署计划，登录到生产环境中，配置统一环境部署步骤，自动化完成生产环境的配置，将环境配置和应用配置集中放置在统一配置库里，利用配置单元6对测试环境、预生产环境、生产环境进行统一部署。
[0098] 对于上述的S5步骤，在进行系统测试、验收测试以及应用上线阶段，都必须对环境进行配置，对应的环境为测试环境、预生产环境以及生产环境，除了配置环境之后，还需要进行二进制包的部署，为各个测试提供基础数据以及适宜的环境。
[0099] 更进一步地，上述的S6步骤，分别对应用进行系统测试、验收测试以及上限发布测试，获取测试后的检查结果的步骤，包括以下具体步骤：
[0100] S61、对应用的环境进行冒烟测试；
[0101] S62、对测试系统的可执行性以及连接系统交互的互通性进行测试；
[0102] S63、对应用的预生产环境进行冒烟测试以及验收测试；
[0103] S64、对应用的生产环境进行冒烟测试。
[0104] 上述的冒烟测试是在将代码更改嵌入到产品的源树中之前对这些更改进行验证的过程，在检查了代码后，冒烟测试是确定和修复
软件缺陷的最经济有效的方法。
[0105] 上述的S61步骤以及S62步骤，具体是进行系统的测试，在将代码更改嵌入到产品的源树中之前对这些更改进行冒烟测试。在检查了代码后，冒烟测试可以确认代码中的更改会按预期运行，且不会破坏整个版本的
稳定性，是确定和修复软件缺陷的经济有效的方法通过系统测试来测试系统的可执行性、连接系统交互的互通性，以确保不同的单元以及需要经常访问的
数据库和其他系统之间可以互联互通，这种测试进行地比单元测试更久，应该在测试环境下的构建服务器上启动。
[0106] 对于上述的S63步骤，具体是进行验收阶段的测试，在应用完成了单元测试、之前各个阶段的冒烟测试和系统测试之后，最终投入生产前进行验收测试，这是技术测试的最后一个阶段，确保应用准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务，验收测试具体是针对预生产环境以及应用代码、版本等相关内容的验收。
[0107] 对于上述的S64步骤，具体是在生产环境下进行冒烟测试，以便确保应用上线的成功。
[0108] 另外，对于上述的S7步骤，将检查结果发送至代码质量管理单元5，进行代码质量管理和分析的步骤，包括以下具体步骤：
[0109] S71、获取插件；
[0110] S72、利用插件对所述检查结果进行再加工处理，获取加工结果；
[0111] S73、通过量化的方式度量加工结果，获取代码质量的变化程度。
[0112] 对于上述的S71步骤至S73步骤，使用配置单元6通过不同的插件对代码检查结果进行再加工处理，通过量化的方式度量代码质量的变化，从而可以方便地对不同规模和种类的应用发布进行代码质量管理。
[0113] 上述的基于自动化运维的持续集成流水线方法，通过从版本控制、环境控制以及测试控制三个方面对应用的上线过程进行自动化优化，形成上线持续集成流水线，提高上线效率，实现持续集成流水线，应用DEVOPS理念，通过技术平台标准化、自动化的执行和落实持续集成，提升应用质量，降低企业管理成本。
[0114] 上述仅以实施例来进一步说明本发明的技术内容，以便于读者更容易理解，但不代表本发明的实施方式仅限于此，任何依本发明所做的技术延伸或再创造，均受本发明的保护。本发明的保护范围以
权利要求书为准。
