CN111443940B - 一种基于DevOps的完整软件生命周期管理方法及系统 - Google Patents

Abstract

本发明公开了一种基于DevOps的完整软件生命周期管理方法，本方法包括：需求的收集与分析；需求的跟踪管理；项目自动化交付过程；监控运维分析以及基于该管理方法构建一个完整软件生命周期的DevOps平台，所述平台包含由收集管理需求并跟踪开发进度构成的需求管理模块；项目创建、代码开发管理、自动化测试及交付管理构成的开发交付模块，项目状态分析、监控与告警管理构成的运维管理模块。本发明不仅加强了前期需求分析与开发进度安排、软件开发、自动化测试和运维监控之间的沟通，还实现了对整个软件生命周期的全方位支持，提高了软件开发的效率。

Description

一种基于DevOps的完整软件生命周期管理方法及系统

技术领域

本发明涉及软件开发方法与技术领域，具体是一种基于DevOps的完整软件生命周期管理方法及系统。

背景技术

DevOps包括自动化、架构设计等一系列软件工程最佳实践，来使得构建、测试、发布软件更加快捷、频繁和可靠。软件生命周期又称软件生存周期或系统开发生命周期，是软件从生产到消亡的生命周期，软件生命周期包含问题定义、可行性分析、软件设计、程序编码、软件测试、运行维护等六大阶段。软件生命周期在软件开发中有着重要的指导意义，目前市场上无论何种开发方式都依然沿用了软件生命周期的概念进行开发。

目前业界有若干独立的实践和工具，但没有统一的标准流程或全生命周期、系统的解决方案。主流的DevOps系统都没有涵盖完整的软件生命周期流程，大部分商业解决方案在Jenkins、Gitlab等开源组件的基础上，通过整合开源工具至一个系统、设置高可用的默认配置方案及提供有着良好交互体验的一站式网站，一定程度上减轻了开发者的配置负担，是成熟的CI/CD(Continuous Integration/Continuous Delivery，持续集成/持续交付)工具，但这些解决方案仅仅帮助了完成开发过程交付自动化，仍未将开发、测试以及后续的部署监控环境集成为一体，未覆盖完整软件生命周期，它们都不算真正的DevOps系统。

所以人们需要一个包含从需求、开发、测试到运维监控阶段的基于DevOps的完整软件生命周期管理方法和系统来解决上述问题。

发明内容

本发明的目的在于提供一种基于DevOps的完整软件生命周期管理方法和系统，来对软件生命周期进行跟踪管理，进而实现对软件生命周期每个环节的掌握与监督，以解决现有技术中的问题。

为实现上述目的，本发明提供了一种基于DevOps的完整软件生命管理方法，包括以下步骤：

步骤S100，进行需求的收集与分析，对需求进行具体划分并与新建代码仓库进行绑定以实现需求分析、部署、追踪管理；

步骤S110，为代码仓库中业务代码创建流水线，通过流水线的执行完成项目开发以及自动化交付；

步骤S120，创建监控指标并配置指标阈值，对完整软件生命周期需求管理的完成进行监控并分析。

步骤S100中包括以下步骤：

步骤S101，全方位获取用户整体需求，将用户整体需求划分成若干微服务，微服务划分成若干具体业务需求；

步骤S102，创建需求看板，将划分好的微服务与业务需求分别填写入看板中的需求卡片，设置需求卡片优先级、需求卡片预计完成的时间；

步骤S103，创建代码仓库，将步骤S102需求卡片绑定到对应代码仓库的分支，将需求卡片优先级最高的分支设置为保护分支；

步骤S104，创建项目，以步骤S101中微服务为基础创建应用，在微服务的环境中填写划分的微服务所在的代码仓库信息、Docker镜像上传地址、集群信息、部署的域名及端口信息。

进一步地，步骤S110中包括以下步骤：

步骤S111，在代码仓库中编写业务代码并上传；

步骤S112，创建流水线，设置流水线触发方式；

步骤S113，在流水线上配置代码仓库地址；

步骤S114，在流水线上配置代码构建方式；

步骤S115，在流水线上配置测试方式及其测试用例；

步骤S116，在流水线上配置代码制品Docker镜像地址；

步骤S117，在流水线上配置部署策略；

步骤S118，执行流水线。

进一步地，步骤S120中包括以下步骤，以下不分先后顺序：

步骤S121，选择API网关访问量、错误率作为监控指标并配置指标阈值；

步骤S122，查看已经部署服务的API网关访问情况；

步骤S123，对步骤S122所属API网关进行API限流管理；

步骤S124，查看API访问数据流量，数据流拓扑图；

步骤S125，查看用户需求收集、部署、开发、管理过程完成情况。

本发明还提供了一种基于DevOps的完整软件生命周期管理系统，其包含：

需求管理模块，需求管理模块用于供用户进行需求的收集与分析，对需求进行具体划分并与新建代码仓库进行绑定以实现需求分析、部署、追踪管理；

开发与交付模块，开发与交付模块用于供用户为代码仓库中业务代码创建流水线，设置流水线触发方式，通过流水线的执行完成项目开发以及自动化交付；

运维管理模块，运维管理模块用于为用户创建监控指标并配置指标阈值，对需求管理的完成进行监控并分析。

进一步地，需求管理模块包括：

需求管理服务模块，需求管理服务模块用于供用户全方位获取需求，辅助提供完整软件生命周期管理系统的微服务划分及看板功能，看板功能还负责对接代码管理服务以追踪看板中需求卡片的状态；

看板功能中含有三级需求卡片，一级需求卡片对应项目，一个项目管理服务中的项目对应需求管理中一个看板，一级需求卡片内有多个二级需求卡片，二级需求卡片对应微服务且每个二级需求卡片绑定至多一个微服务的开发仓库，二级需求卡片内含有多个三级需求卡片，一个三级需求卡片绑定对应二级需求卡片下微服务的一个开发分支，用于跟踪对应微服务具体业务需求的开发进展；

需求卡片有状态转移以及优先级排序，需求卡片的状态转移与代码管理服务开发分支是否合并入主分支有关，需求卡片的状态有:待处理、处理中、已完成、已取消；三级需求卡片创建时为“待处理”状态；三级需求卡片中分支处于开发中，三级需求卡片由“待处理”状态变为“处理中”状态；三级需求卡片中开发分支合并入代码仓库的主分支，三级需求卡片由“处理中”状态变为“已完成”状态；

过程管理服务模块，过程管理服务模块用于供用户收集微服务需求、开发、部署监控过程中的产生的过程性数据，并进行数值化分析；

进一步地，过程管理服务包括：

日志采集单元，日志采集单元用于收集软件生命周期服务中产生的日志信息，并将日志信息分类制作标签，便于查阅；

数据分析单元，数据分析单元用于统计计算日志采集单元采集的服务需求的过程性数据指标。

进一步地，开发与交付模块为用户提供以下服务：

(1)项目管理服务，提供集群的管理配置以及项目的管理；创建项目，用于创建项目，项目绑定一个代码管理服务中对应该项目的一个或多个代码地址；创建应用，用于创建项目的微服务，一个项目对应一个或多个微服务，一个微服务绑定一个代码管理服务中的项目代码仓库地址或为代码仓库中的一部分，该微服务在绑定的项目代码地址下开发；一个微服务绑定一个容器镜像管理服务中的一个镜像地址，该地址用于将该微服务最终的Docker镜像制品的上传地址；创建环境，用于创建微服务部署的环境，一个微服务对应一个或多个环境，环境中包含微服务所部署的Kubernetes集群地址、Kubernetes的命名空间、副本个数、微服务部署的的目标端口、微服务部署的目标地址；

(2)代码管理服务，用于提供Git分支、标记、推送及合并代码的功能；

(3)流水线管理服务，用于实现完整的持续集成/持续交付流程，其中，通过对接代码管理服务完成代码仓库的拉取、构建及部署功能，通过对接容器镜像管理服务完成镜像的构建、推送功能，通过对接项目管理服务完成部署的功能，让用户可以同时对项目进行软件集成、软件交付功能，缩短软件开发的时间与成本；

(4)容器镜像管理服务，管理上述代码管理服务打包的代码Docker制品，提供镜像标记、权限、推送、拉取的功能；

(5)测试管理服务，提供API接口测试、静态代码检测的自动化测试功能；

项目管理服务包括：

项目管理单元，项目管理单元用于管理项目的生命周期流程，并将项目绑定至代码管理服务中的一个或多个代码仓库地址；

应用管理单元，应用管理单元用于管理项目下多个应用即划分后的微服务的生命周期流程，每一个应用对应容器镜像服务中的一个镜像地址；

环境管理单元，环境管理单元用于管理环境的生命周期流程以及部署条件；

在上述创建流水线过程中，一条流水线绑定一个微服务，为该微服务从开发仓库到代码构建、代码测试、制作Docker镜像、上传Docker镜像、部署创建自动化脚本；

流水线触发方式包括：

手动触发流水线，手动触发流水线用于手动点击启动微服务的部署；

定时触发流水线，定时触发流水线用于创建定时装置，根据约定的时间间隔定时触发流水线；

自动触发启动流水线，自动触发启动流水线用于流水线绑定的代码仓库主分支有合并时触发流水线。

进一步地，运维管理模块包括：

(1)监控告警服务，对部署的微服务的多个指标进行监控并根据所填指标阈值告警；监控指标包括但不限于微服务所占用CPU使用情况、微服务所占用内存使用情况、微服务API请求数量、微服务运行时长、微服务运行状态、微服务被告警的次数；

(2)API网关服务，用于对部署的微服务的API进行收集、管理、流量控制；用于收集、展示部署微服务的所有API；配置API的限流、熔断、路由在内的多种策略；用于搜索、查看API的被请求次数、被请求时的状态；用于收集API的各项指标及信息，并进行可视化的展示；

(3)链路分析服务，用于对一个项目中所部署的多个微服务之间进行追踪数据、消息的流向。

与现有技术相比，本发明的有益效果是：本发明提供的一种基于DevOps的完整软件生命周期管理方法和系统，对软件生命周期的每个环节都有详细说明，通过对Kubernetes、Gitlab、Jenkins、Maven、Harbor、SonarQube、Prometheus、Kong、Zipkin 多种开源工具的整合，辅助完成一个完整的软件生命周期；在软件的整个工作过程中，本发明提供的方法与系统为软件需求以及任务进程降低成本，同时加速软件开发周期，为持续部署与交付提供可靠支持，为后期运维提供自动化保障，符合现代与未来软件生命周期管理的场景。

附图说明

图1是本发明实施例一中的一种基于DevOps的完整软件生命周期管理方法的流程图；

图2是本发明实施例一中的一种基于DevOps的完整软件生命周期管理方法的需求管理模块流程图；

图3是本发明实施例一中的一种基于DevOps的完整软件生命周期管理方法的开发与交付模块流程图；

图4是本发明实施例一中的一种基于DevOps的完整软件生命周期管理方法的运维管理模块流程图；

图5是本发明实施例二中的一种基于DevOps的完整生命软件周期管理系统；

图6是本发明实施例二中的一种基于DevOps的完整软件生命周期管理系统的系统框图；

图7是本发明实施例二中的一种基于DevOps的完整软件生命周期管理系统的需求管理模块的内部系统结构框图；

图8是本发明实施例二中的一种基于DevOps的完整软件生命周期管理系统的开发与交付模块的内部系统结构框图；

图9是本发明实施例二中的一种基于DevOps的完整软件生命周期管理系统的运维模块的内部内部系统结构框图；

图10是本发明实施例二中的一种基于DevOps的完整软件生命周期管理系统的案例架构图。

具体实施方式

本文使用的术语“微服务”为项目划分之后的结果，管理中的应用管理对微服务进行管理，所以本文中微服务与应用的概念等同。

本文使用的术语“持续集成/持续交付”，即CI/CD(Continuous Integration/Continuous Delivery)，持续集成是一种软件开发实践，是指开发阶段对项目进行持续性自动化编译、测试，以达到控制代码质量的手段；持续交付是一种软件工程手法，让软件产品的产出过程在一个短周期内完成，以保证软件可以稳定、持续的保持在随时可以释出的状况，它的目标在于让软件的开发、测试与释出变得更快以及更频繁，这种方式可以减少软件开发的成本与时间，同时减少软件开发需承担的风险。

本文使用术语“需求看板”，看板Kanban概念源于丰田精益生产系统，轻量、灵活和简单的团队协作方法，看板协作是一种流行的轻量、灵活和简单的团队协作方法，它将项目的需求、缺陷和任务可视，让每个人一目了然地掌握每项工作的状态，团队通过拉动工作“需求卡片”更新工作进展，及时暴露风险和问题。

本文使用术语“需求卡片”即上述在需求看板中，将项目目标分割成可用完成时间量化的小目标，并将可视化的小目标写在需求卡片。

本文使用术语“Webhook”，Webhook是一个API概念，即在代码管理服务中填写流水线管理服务的运行地址，代码管理服务发现有代码合并进入主分支时，运行上述地址，完成流水线管理服务的自动触发操作。

本文使用术语“Docker”，Docker是一个开放源代码软件、一个开放系统，用于开发应用、交付应用、运行应用，Docker允许用户将基础设施中的应用单独分割出来，形成更小的颗粒(容器)，从而提高交付软件地速度。Docker容器与虚拟机类似，但原理上，容器是将操作系统层虚拟化，虚拟机则是虚拟化硬件，因此容器更具有便携性、高效地利用服务器，容器更多的用于表示软件的一个标准化单元，由于容器的标准化，因此它可以无视基础设施的差异，部署到任何一个地方，另外，Docker也为容器提供更强的业界的隔离兼容。

本文使用术语“Harbor”，是构建企业级私有docker镜像的仓库的开源解决方案，是Docker Registry的更高级封装，它除了提供友好的Web UI界面、角色，还提供用户权限管理、用户操作审计等功能。

本文使用术语“Kubernetes”，是用于自动部署、扩展和管理容器化应用程序的开源系统，旨在提供跨主机集群的自动部署、扩展以及运行应用程序容器的系统，Kubernetes在设计结构上定义了一系列的构建模块，其目的是为了提供一个可以共同提供部署、维护和扩展应用程序的机制，组成Kubernetes的组件设计概念为松耦合和可扩展的，这样可以使之满足多种不同的工作负载。

本文使用术语“API”，即Application Programming Interface应用程序接口，是在因特网上的端系统提供了的应用程序接口，又称为应用程序编程接口，是软件系统不同组成部分衔接的约定，API规定了运行在一个端系统上的软件请求因特网基础设施向运行在另一个端系统上的特定目的地软件交付数据的方式。

本文使用术语“API网关”，API网关，即API Gateway应用程序接口网关，是大型分布式系统中，为了保护内部服务而设计的一道屏障，可以提供高性能、高可用的API托管服务，从而帮助服务的开发者便捷地对外提供服务，而不用考虑安全控制、流量控制、审计日志等问题，API网关统一在网关层将安全认证、流量控制、审计日志、黑白名单等实现；网关的下一层是内部服务，内部服务只需开发和关注具体业务相关的实现，网关可以提供API发布、管理、维护等主要功能,开发者只需要简单的配置操作即可把自己开发的服务发布出去，同时置于网关的保护之下。

本文使用术语“Gitlab”，GitLab是使用MIT许可证的基于网络的Git仓库管理工具，且具有Wiki和Issue跟踪功能,使用Git作为代码管理工具，并在此基础上搭建起来的Web服务。

本文使用术语“Jenkins”，Jenkins提供了软件开发的持续集成服务,它运行在Servlet容器中支持软件配置管理(SCM)工具(包括AccuRev SCM、CVS、Subversion、Git、Perforce、Clearcase和RTC)，可以执行基于Apache Ant和Apache Maven的项目以及任意的Shell脚本和Windows批处理命令,并且可以通过各种手段触发构建。

本文使用术语“Jenkinsfile”，为Jenkins的配置文件，是用文件的形式将流水线组织起来，一个Jenkinsfile可以代表一条流水线，Jenkins装配一个现有Jenkinsfile 便可直接运行。

本文使用术语“SonarQube”，Sonar是一个用于代码质量管理的开源系统，用于管理Java源代码的质量，通过集成不同的测试、代码分析工具，加上插件对这些分析结果进行加工处理，以量化的方式度量代码质量的变化，从而可以方便地对不同规模和种类的工程进行代码质量管理。

本文使用术语“Prometheus”，Prometheus是由SoundCloud开源监控告警解决方案，存储时序数据并进行展示。

本文使用术语“Kong”，Kong是一个开箱可用的API网关管理工具，采用插件机制进行功能定制，插件集(可以是0或N个)在API请求响应循环的生命周期中被执行。

本文使用术语“Zipkin”，Zipkin是一款开源的分布式实时数据追踪系统，它的主要功能是聚集分布式系统中各个节点的实时监控数据，Zipkin主要分为两个部分，一个部分是Zipkin服务端，作为中心节点用于数据采集存储、分析及可视化展示，另一个部分是Zipkin客户端，作为从属节点部署在需要收集数据的节点上，用于生产、上报追踪数据。

本文使用术语“Django”，Django是一个基于Python语言开源的Web开发框架，采用MVC架构软件设计模式，提供了完善的对象关系映射、路由功能、视图模板、后台管理系统和缓存支持。

本文使用术语“SDK”，全称Software Development Kit，即软件开发工具包，SDK是一组开发工具的集合，被软件工程师用来开发软件、系统及操作系统等，它主要包含针对该开发工具集的介绍，和开发工具集本身。

本文使用术语“Spring”，Spring是一个开发应用框架，具有轻量级、非侵入式、一站式、模块化特点，主要用于简化企业级应用程序开发，通过内置多个框架和技术，为开发者提供便捷的开发功能。

本文使用术语“Maven”，Maven是一个跨系统的项目管理和构建工具，主要服务与Java系统，提供项目构建、依赖管理和项目信息管理的功能，通过将项目所需依赖集中进行管理，Maven解决了项目在不同系统的依赖问题。

本文使用术语“Node”，又被称为Node.js，是一个面向web应用的服务器程序，它基于Google V8引擎和JavaScript语言，通过异步编程与事件驱动解决了多线程访问时的资源和性能消耗问题。

实施例一：请参阅图1所示，本实施例的技术方案提出了一种基于DevOps的完整软件生命周期管理方法，该方法以用户为主体，为用户的开发过程提供便捷，引导用户在软件开发的各阶段都可以实现DevOps最佳时间，具体包括如下步骤：

步骤S100，如图2所示，进行需求的收集与分析，对需求进行具体划分并与新建代码仓库进行绑定以实现需求分析、部署、追踪管理。

在本实施例中，提供一种具体的需求跟踪管理方法，包括：

步骤S101，全方位获取用户整体需求，并且将用户整体需求划分成若干微服务，微服务划分成若干具体业务需求；

步骤S102，创建需求看板，将划分好的微服务与业务需求分别填写入看板中的需求卡片，设置需求卡片优先级、需求卡片预计完成的时间；

步骤S103，创建代码仓库，将步骤S102需求卡片绑定到对应代码仓库的分支，将需求卡片优先级最高的分支设置为保护分支；

步骤S104，创建项目，以步骤S101中微服务为基础创建应用，在微服务的环境中填写划分的微服务所在的代码仓库信息、Docker镜像上传地址、集群信息、部署的域名及端口信息。

上述步骤S101-S104为步骤S100的具体阐述。

步骤S110,如图3所示，项目开发，为代码仓库中业务代码创建流水线，通过流水线的执行完成项目开发以及自动化交付，具体步骤如下：

步骤S111，在代码仓库中编写业务代码并上传；

步骤S112，创建流水线，设置流水线触发方式，其中触发方式有：手动触发、定时触发、自动触发，手动触发流水线，用于手动点击启动微服务的部署；定时触发流水线，用于创建定时装置，根据约定的时间间隔定时触发流水线；自动触发启动流水线，用于流水线绑定的代码仓库主分支有合并时触发流水线；

步骤S113，在流水线上配置代码仓库地址，代码仓库可以是现有的仓库地址，也可以是新建仓库地址；

步骤S114，在流水线上配置代码构建方式；

步骤S115，在流水线上配置测试方式及其测试用例；

步骤S116，在流水线上配置代码制品Docker镜像地址；

步骤S117，在流水线上配置部署策略；

步骤S118，执行流水线，若流水线执行不成功，开发人员可修改代码重启流水线。

步骤S120，如图4所示，监控运维分析。步骤S120包含以下步骤：

步骤S121，选择API网关访问量、错误率作为监控指标并配置指标阈值；

步骤S122，查看已经部署服务的API网关访问情况；

步骤S123，对步骤S122所属API网关进行API限流管理；

步骤S124，查看API访问数据流量，数据流拓扑图；

步骤S125，查看用户需求收集、部署、开发、管理过程完成情况；上述步骤不分先后顺序，注意，上述监控指标包括但不限于微服务所占用CPU使用情况、微服务所占用内存使用情况、微服务API请求数量、微服务运行时长、微服务运行状态、微服务被告警的次数。需求过程完成指标包括但不限于一次业务过程中的交付周期、部署频率、成功率、测试通过率、服务恢复时间(时间窗口)、完成需求卡片的平均耗时。

实施例二：参照图5和图6，发明实施例所提供的一种基于DevOps的完整软件生命周期管理系统包括需求管理模块210，开发与交付模块220，运维管理模块230。

上述完整软件生命周期的DevOps系统整合了Kubernetes、Gitlab、Jenkins、Maven、Harbor、SonarQube、Prometheus、Kong、Zipkin开源工具。

需求管理模块210如图7所示，包含了需求的收集与管理的需求管理服务模块 211以及跟踪需求开发进度的过程管理服务模块212；

需求管理服务模块211使用看板工具，快速收集、管理需求的各项信息，并进行可视化的展示。该服务负责将需求划分为微服务以及更小的业务需求，展示清晰的需求关系的同时还提供良好的交互式操作对需求进行生命周期管理。示例性的，使用 React框架搭建具备Kanban功能的Web页面，用户可以在该页面新建、编辑、删除需求卡片，可以设置一个需求卡片与其下属需求卡片的对应关系，可以拖拽需求卡片使其移动至不同的分组，该服务将与代码管理服务进行绑定，在进行代码提交、合并、删除等操作时，同步更新需求的状态，同时，该服务将绑定Gitlab仓库的Webhook，当Gitlab触发提交、合并、删除操作时，触发内部的响应函数，对绑定需求卡片进行增删改查的操作。最后，该服务还负责向过程管理服务提供需求信息及日志信息，以便其进行软件过程管理,该服务主要为过程管理服务提供多个API，以便过程管理服务使用API获取所需相关信息。

过程管理服务模块212使用日志采集单元收集本文所有服务的日志信息，并将日志信息进行分类、打标签，便于查询。在数据分析单元中，根据所收集到的所有日志，联合需求管理服务以及流水线管理服务的日志，计算出完成一个微服务的部署频率、成功率、交付周期，以及完成整个项目的部署频率、成功率、交付周期；根据测试管理服务所提供的数据，计算出该项目或者微服务关于某个测试的测试通过率，示例性的，收集到的需求管理服务相关日志，根据得到完成所有需求卡片的总耗时，可以计算出完成需求卡片的平均耗时。

开发与交付模块220如图8所示，包含了提供Kubernetes集群的管理配置以及项目管理的项目管理服务221；整合Gitlab提供Git分支、标记、推送及合并代码的代码管理服务222；依托于Jenkins提供流水线配置对接代码管理服务，完成所选测试，将代码制品部署到项目管理服务所管理的Kubernetes集群的流水线服务223；使用Harbor保存打包镜像制品，供Kubernetes拉取镜像的容器镜像管理服务224；提供接口测试、代码静态扫描等功能的测试管理服务225。

上述项目管理服务221，管理的项目和应用的生命周期流程以及对项目、应用各类信息的增删改查，示例性的，该服务使用React框架搭建的Web页面，进行项目及应用的增加、删除、编辑；其内容包括项目的名称、创建人、项目描述、项目所属人员、项目下的应用；应用中包括应用名称、创建人、修改人、应用描述、应用环境、应用变量的显示；应用环境中包括集群地址、Kubernetes Service配置、Kubernetes Deployment配置与KubernetesIngress配置，同时，该服务还与代码管理服务、镜像仓库管理服务、流水线管理服务对接，收集、传递项目持续交付流程所需的配置信息，并使用代码管理及镜像管理服务的API，获取用户可以访问的代码仓库和镜像仓库并收集至应用信息中，同时，该服务对流水线服务提供接口，使得流水线服务在构建过程中可以从该服务获取配置所需信息。对于每一个应用还管理其部署环境的生命周期流程，在应用环境中可以设定部署的各类参数，与Kubernetes集群以及流水线管理服务进行绑定，不仅支持将构建信息传递给流水线管理服务，还可以直接将Kubernetes 组件部署到集群中，示例性的，该服务使用KubernetesJAVASDK，将配置好的 Service、Ingress通过Kubernetes API部署至Kubernetes集群中，使其可以访问与使用。

上述代码管理服务222，依托于Gitlab满足在代码开发过程中对于代码的版本控制，代码管理服务222会把各个版本保存起来完成一系列功能，如：为每一次变更提交版本更新并且备注更新的内容；在项目的各个历史版本之间自如切换；比较出两个版本之间的差异；从当前的修改中撤销一些操作。代码管理服务222还能创建分支、合并分支，完成多人协作开发，除此之外，支持Webhook功能，当有分支提交合并入主分支时，通知需求管理服务以及流水线管理服务完成对应的操作。示例性的包括，通过自建Gitlab并且调用自建Gitlab的API结合自身的数据库完成如下功能：代码仓库方面，新建代码仓库、查询代码仓库列表、检索代码仓库、删除代码仓库；仓库管理方面，当有提交的代码进入仓库时，会将代码通过API转入Gitlab并在数据库进行保存，前端展示分支、标签、统计等功能触发对应的功能将会直接对接到具体的 Gitlab仓库，做到自身Gitlab仓库与代码管理服务的一致。

流水线管理服务223，依托于自建Jenkins提供一种易于使用的CI/CD流程，对系统使用者的技术要求低，流水线管理服务中可以自由组合添加删除流水线各个阶段，在每个阶段中装配流水线阶段所要完成的任务，并提供各种流水线阶段装配的任务，如：拉取代码、接口测试、代码静态扫描、构建docker镜像、推送Docker镜像、部署以及Maven、Node、Django等各种语言的构建。流水线管理服务内部配置有 Jenkinsfile模板，根据前端展示流水线上配置的内容填充Jenkinsifle，配置完各个流水线阶段任务之后，流水线管理服务223会自动生成Jenkinsfile载入Jenkins中，可选的，流水线管理服务可以直接导入用户的Jenkinsfile完成流水线的构建，当Jenkins 的流水运行时，流水线管理服务223会时刻监听流水线的运行并获取到流水线个阶段的运行结果反馈给前端。

容器镜像管理服务224，通过搭建私有Harbor镜像仓库为软件产品的打包部署进行保障，通过镜像保存软件产品更加快捷方便，部署时从仓库中拉取相应镜像并创建容器即可；在容器镜像管理服务中，提供镜像的推送、拉取、检索和删除等相关管理功能，还提供仓库用户的管理功能以及详细的镜像信息展示，通过在服务器上搭建私人Harbor镜像仓库，当代码编写完毕后，通过系统中前端界面调用Harbor的API，将代码制品打成镜像并上传到仓库中，完成推送，通过前端界面也可以进行关键字搜索过滤，对容器镜像仓库中镜像进行检索，还可以调用相关API进行镜像的删除。

测试管理服务225，又可细分为静态代码测试和动态接口测试，对于静态代码测试，通过代码分析工具SonarQube对代码仓库中的代码提供检测，调用SonarQube相关API通过词法分析、语法分析、控制流、数据流分析等技术对程序代码进行扫描，来验证代码是否满足规范性、安全性、可靠性、可维护性的要求，在一次构建的代码被编译部署之前，对仓库中的代码行数、种类、目录数及文件数进行扫描并且将检查结果通过可视化页面展示，展示的结果包括代码不规范编写、代码移位的具体部分，对于动态接口测试，提供测试用例书写、测试用例分组、测试用例执行、回归测试、性能测试、测试报告生成等一系列的测试功能，针对一系列已经部署好的项目后端接口，编写测试用例，添加相关配置，包括但不限于接口的URL地址、不合法的接口参数、合法的接口参数、接口的调用次数、接口的响应时间要求、接口的预期结果、接口的分组信息，选择手动触发或自动触发，最终展示每个接口的成功率。

运维管理模块230如图9所示，包含了使用Prometheus监控部署后微服务的多个运行指标以及根据各个指标所填阈值告警的监控告警服务231；使用Kong结合 ingress用于对部署的微服务的API进行收集、管理、流量控制的API网关服务232；借助Zipkin对一个项目中所部署的多个微服务之间进行追踪数据、消息的流向的链路分析服务233。

上述监控告警服务231用于抓取Kubernetes上部署的Prometheus采集的指标，通过HTTP协议周期性抓取被监控组件的状态，任意组件只要提供HTTP接口就可以接入监控系统，不需要任何SDK或者其他的集成过程；监控告警服务231抓取到指标后进行可视化分析，同时可以对各种指标设定阈值，当监控告警服务监听到指标超过设定阈值时将进行告警，发送邮件通知项目负责人及时进行处理。

API网关服务232用于监控、管理已经部署的服务的API接口，通过开源工具收集、展示所有API接口并提供完整的生命周期管理同时，该服务还负责收集API 访问的日志信息，以可视化的形式展现API的多项指标，例如，错误率、访问量等；最后，该服务还将负责设置API接口的限流策略、熔断策略、路由策略、安全策略、全方位地定义、管理API的各项功能，示例性的，该服务使用Kong来收集、管理所有API，使用React搭建的Web页面对API进行增加、编辑、删除、查询的操作，通过Kong实现上述日志信息的收集及API策略的管理，通过React搭建的Web页面进行指标可视化的展示。

链路分析服务233，通过Zipkin等开源工具获取软件运行时日志并进行分析，可视化展示微服务架构各服务间关系拓扑图并记录和展示每次服务调用的具体路径，链路追踪显示所有服务之间的调用详情数据，每一次服务被调用时，通过TraceId记录这次调用的完整链路数据，记录经过的服务数、请求开始时间、耗时、请求结果等详细信息，展示完整的链路及错误日志信息帮助使用者进行错误的追踪和精确定位，在链路分析服务中，提供交互良好的整体服务架构拓扑图，链路访问记录列表以及对链路的查询和收藏服务，本服务对故障追踪排查及运维监控提供可靠保障。

实施例三：基于上述原理，利用支持完整软件生命周期的DevOps方法搭建一个实例化系统，其架构如图10所示，帮助用户完成一个基于Spring开发的在线商城项目，具体搭建步骤如下：

需求管理模块210用于进行需求的收集与分析，对需求进行具体划分并与新建代码仓库进行绑定以实现需求分析、部署、追踪管理，具体实施过程如下：

用户全方位获取需求，并且将整体需求划分成用户管理服务、商品管理服务、订单管理服务；用户在需求管理服务模块211中创建看板，并将这些服务分别填入看板的二级需求卡片中。以商品管理服务为例，可以将用户管理服务的具体业务需求如：商品添加、商品更新、商品下架分别填写入商品管理服务二级需求卡片对应的三级需求卡片下，并分别设定其优先级，预计完成的时间等信息。

开发与交付模块模块220用于为代码仓库中业务代码创建流水线，通过流水线的执行完成项目开发以及自动化交付，具体实施过程如下：用户在代码管理服务222中创建代码仓库，将需求卡片优先级最高的分支设为为保护分支，创建与上述需求卡片对应的分支，并回到需求管理服务模块211将需求卡片绑定到相应分支；用户在项目管理服务221中创建项目，填写对应的描述，在所建项目下创建与需求管理二级需求卡片对应的用户管理微服务、商品管理微服务、订单管理微服务，以商品管理微服务为例，用户进入商品管理微服务创建若干部署环境，如测试环境、开发环境、部署环境，并在环境下配置集群信息并填写代码上传地址、打包Docker镜像上传的名称、部署的域名以及端口信息，用户代码仓库划分为用户管理文件夹、商品管理文件夹、订单管理文件夹，分别在各自的文件夹中创建Spring项目并上传编写的业务代码。用户在流水线管理服务223中对单个微服务如商品管理服务，创建一条流水线，并且选择自动触发，即当代码仓库中代码合并入主分支就运行流水线，对用户有可选项的流水线中配置流水线如下：拉取代码仓库对应代码、选择进行代码静态扫描测试、选择Maven构建、选择打包Docker镜像并上传、选择部署的环境；当代码仓库中有代码合并入主分支时，流水线管理服务223会将用户上述配置的流水线运行完毕，若流水线运行无误，将会在用户填写的域名下看见对应的服务，且在测试服务中看见代码分析报告。

运维管理模块用于创建监控指标并配置指标阈值，对完整软件生命周期需求管理的完成进行监控并分析，具体步骤如下：

用户进入监控告警服务231，查看刚刚部署成功的商品管理服务的运行状态，如：该微服务所占用CPU使用情况、内存使用情况等，用户可以通过设定，对CPU占用超过比例的应用进行报警处理；用户在API网关服务232可查看具体部署服务的 API访问情况，如对商品管理服务而言，通过查看增加商品API的运行状态，被调用的次数，若感觉该API压力过大，可以选择API限流策略，如一定周期内限制被访问次数的多少；用户在链路分析服务233中查看具体商品数据在各个部署微服务之间的流转以及数据访问情况。

Claims (8)

1.一种基于DevOps的完整软件生命周期管理系统，其特征在于，包括：

需求管理模块(210)，所述需求管理模块(210)用于供用户进行需求的收集与分析，对需求进行具体划分并与新建代码仓库进行绑定以实现需求分析、部署、追踪管理；

开发与交付模块(220)，所述开发与交付模块(220)用于供用户为代码仓库中业务代码创建流水线，设置流水线触发方式，通过流水线的执行完成项目开发以及自动化交付；

运维管理模块(230)，所述运维管理模块(230)用于为用户创建监控指标并配置指标阈值，对需求管理的完成进行监控并分析；

所述需求管理模块(210)包括：

需求管理服务模块(211)，所述需求管理服务模块(211)用于供用户全方位获取需求，辅助提供完整软件生命周期管理系统的微服务划分及看板功能，所述看板功能还负责对接代码管理服务以追踪看板中需求卡片的状态；

在所述看板功能中含有三级需求卡片，其中，第一级需求卡片对应项目，第二级需求卡片对应微服务，第三级需求卡片对应微服务具体的业务需求；所述三级需求卡片均具备状态转移以及优先级排序，所述状态转移与代码管理服务开发分支是否合并入主分支有关；

过程管理服务模块(212)，所述过程管理服务模块(212)用于供用户收集微服务需求、开发、部署监控过程中的产生的过程性数据，并进行数值化分析；

所述过程管理服务模块(212)包含：

日志采集单元，所述日志采集单元用于收集软件生命周期服务中产生的日志信息，并将日志信息分类制作标签，便于查阅；

数据分析单元，所述数据分析单元用于统计计算所述日志采集单元收集到的服务需求的过程性数据指标。

2.根据权利要求1所述的一种基于DevOps的完整软件生命周期管理系统，其特征在于，所述开发与交付模块(220)包括：

项目管理服务(221)，所述项目管理服务(221)用于供用户创建集群并对多个项目进行管理，同时供用户设置应用的服务项目，并将项目绑定至代码管理服务中；

代码管理服务(222)，所述代码管理服务(222)用于提供Git分支、标记、推送及合并代码的功能；

流水线管理服务(223)，所述流水线管理服务(223)用于实现完整的持续集成/持续交付流程，所述流水线管理服务(223)，通过对接代码管理服务完成代码仓库的拉取、构建及部署功能，通过对接容器镜像管理服务完成镜像的构建、推送功能，通过对接项目管理服务完成部署的功能，让用户可以同时对项目进行软件集成、软件交付的功能；

容器镜像管理服务(224)，所述容器镜像管理服务(224)用于管理所述代码管理服务构建的Docker镜像，提供镜像标记、权限、推送、拉取功能；

测试管理服务(225)，所述测试管理服务(225)用于供用户部署微服务的API接口测试和验证代码是否符合要求的静态代码检测。

3.根据权利要求2所述的一种基于DevOps的完整软件生命周期管理系统，其特征在于：

所述项目管理服务(221)包括：

项目管理单元，所述项目管理单元用于管理项目的生命周期流程，并将项目绑定至代码管理服务中的一个或多个代码仓库地址；

应用管理单元，所述应用管理单元用于管理项目下多个应用即划分后的微服务的生命周期流程，每一个应用对应容器镜像服务中的一个镜像地址；

环境管理单元，所述环境管理单元用于管理环境的生命周期流程以及部署条件；

在所述创建流水线中，一条流水线绑定一个微服务，为该微服务从开发仓库到代码构建、代码测试、制作Docker镜像、上传Docker镜像、部署创建自动化脚本；

所述流水线触发方式包括：

手动触发流水线，所述手动触发流水线用于手动点击启动微服务的部署；

定时触发流水线，所述定时触发流水线用于创建定时装置，根据约定的时间间隔定时触发流水线；

自动触发启动流水线，所述自动触发启动流水线用于流水线绑定的代码仓库主分支有合并时触发流水线。

4.根据权利要求1所述的一种基于DevOps的完整软件生命周期管理系统，其特征在于，所述运维管理模块(230)包括：

监控告警服务(231)，所述监控告警服务(231)对部署的微服务的多个指标进行监控并根据所填指标阈值告警；

API网关服务(232)，所述API网关服务(232)用于对部署的微服务API进行信息收集、API生命周期流程管理以及流量控制；

链路分析服务(233)，所述链路分析服务(233)用于对一个项目中所部署的多个微服务之间进行追踪数据、消息的流向。

5.一种应用于权利要求1-4中任一项的基于DevOps的完整软件生命周期管理系统的基于DevOps的完整软件生命周期管理方法，其特征在于，包括以下步骤：

步骤S100，进行需求的收集与分析，对需求进行具体划分并与新建代码仓库进行绑定以实现需求分析、部署、追踪管理；

步骤S110，为代码仓库中业务代码创建流水线，通过流水线的执行完成项目开发以及自动化交付；

步骤S120，创建监控指标并配置指标阈值，对完整软件生命周期需求管理的完成进行监控并分析。

6.根据权利要求5所述的一种基于DevOps的完整软件生命周期管理方法，其特征在于，在所述步骤S100中包括以下步骤：

步骤S101，全方位获取用户整体需求，将用户整体需求划分成若干微服务，微服务划分成若干具体业务需求；

步骤S102，创建需求看板，将划分好的微服务与业务需求分别填写入看板中的卡片，设置卡片优先级、卡片预计完成的时间；

步骤S103，创建代码仓库，将步骤S102所述卡片绑定到对应代码仓库的分支，将卡片优先级最高的分支设置为保护分支；

步骤S104，创建项目，以步骤S101中所述微服务为基础创建应用，在微服务的环境中填写划分的微服务所在的代码仓库信息、Docker镜像上传地址、集群信息、部署的域名及端口信息。

7.根据权利要求5所述的一种基于DevOps的完整软件生命周期管理方法，其特征在于，在所述步骤S110中包括以下步骤：

步骤S111，在代码仓库中编写业务代码并上传；

步骤S112，创建流水线，设置流水线触发方式；

步骤S113，在流水线上配置代码仓库地址；

步骤S114，在流水线上配置代码构建方式；

步骤S115，在流水线上配置测试方式及其测试用例；

步骤S116，在流水线上配置代码制品Docker镜像地址；

步骤S117，在流水线上配置部署策略；

步骤S118，执行流水线。

8.根据权利要求5所述的一种基于DevOps的完整软件生命周期管理方法，其特征在于，在所述步骤S120中包括以下步骤：

步骤S121，选择API网关访问量、错误率作为监控指标并配置指标阈值；

步骤S122，查看已经部署服务的API网关访问情况；

步骤S123，对步骤S122所属API网关进行API限流管理；

步骤S124，查看API访问数据流量，数据流拓扑图；

步骤S125，查看用户需求收集、部署、开发、管理过程完成情况。

Images