一种DevOps实现方法、装置、电子设备及存储介质与流程

一种devops实现方法、装置、电子设备及存储介质
技术领域
1.本技术实施例涉及汽车技术领域，尤其涉及一种devops实现方法、装置、电子设备及存储介质。


背景技术：

2.当今的中国互联网，正加速从消费互联网向产业互联网转型，数字化变革逐渐渗透到每一个具体产业，汽车行业面临网联化、智能化、数字化的巨大挑战，车企的转型升级之路迫在眉睫。devops作为数字化时代it研发和管理范式，是企业数字化转型重要的组成部分。
3.devops是一组过程、方法与系统的统称，用于促进开发(应用程序/软件工程)、技术运营和质量保障(qa)部门之间的沟通、协作与整合。它是一种重视“软件开发人员(dev)”和“it运维技术人员(ops)”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。然而如何实现devops落地实施面临着许多挑战，例如，对于多模块项目的开发，参与团队人员较多，跨职能协作较多，信息不透明，协作效率不高；产品发布规范性差，测试环境和生产环境使用镜像管理混乱等。


技术实现要素：

4.本技术提供一种devops实现方法、装置、电子设备及存储介质，可以有效地保证devops落地实施，从而可以使得构建、测试、发布软件能够更加地快捷、频繁和可靠。
5.第一方面，本技术实施例提供了一种devops实现方法，所述方法包括：
6.接收webhook发送的giteewebhookpost消息；其中，所述giteewebhookpost消息包括以下其中之一：pushhook消息、tagpushhook消息、pullrequesthook消息；
7.对所述giteewebhookpost消息进行解析，得到工作人员触发gitee代码仓库的事件的类型；其中，所述工作人员触发gitee代码仓库的事件的类型包括：所述工作人员向所述gitee代码仓库中提交应用代码、所述工作人员在所述gitee代码仓库中的至少一个应用代码中标记版本、所述工作人员将子分支中的应用代码合并到主干分支中；
8.根据所述工作人员触发gitee代码仓库的事件的类型，对待处理的应用代码执行对应的流水线操作。
9.第二方面，本技术实施例还提供了一种devops实现装置，所述装置包括：接收模块、解析模块和执行模块；其中，
10.所述接收模块，用于接收webhook发送的giteewebhookpost消息；其中，所述giteewebhookpost消息包括以下其中之一：pushhook消息、tagpushhook消息、pullrequesthook消息；
11.所述解析模块，用于对所述giteewebhookpost消息进行解析，得到工作人员触发gitee代码仓库的事件的类型；其中，所述工作人员触发gitee代码仓库的事件的类型包
括：所述工作人员向所述gitee代码仓库中提交应用代码、所述工作人员在所述gitee代码仓库中的至少一个应用代码中标记版本、所述工作人员将子分支中的应用代码合并到主干分支中；
12.所述执行模块，用于根据所述工作人员触发gitee代码仓库的事件的类型，对待处理的应用代码执行对应的流水线操作。
13.第三方面，本技术实施例提供了一种电子设备，包括：
14.一个或多个处理器；
15.存储器，用于存储一个或多个程序，
16.当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现本技术任意实施例所述的devops实现方法。
17.第四方面，本技术实施例提供了一种存储介质，其上存储有计算机程序，该程序被处理器执行时实现本技术任意实施例所述的devops实现方法。
18.第五方面，提供了一种计算机程序产品，当所述计算机程序产品被计算机设备执行时实现本技术任意实施例所述的devops实现方法。
19.本技术实施例提出了一种devops实现方法、装置、电子设备及存储介质，先接收webhook发送的gitee webhook post消息；然后对gitee webhook post 消息进行解析，得到工作人员触发gitee代码仓库的事件的类型；再根据工作人员触发gitee代码仓库的事件的类型，对待处理的应用代码执行对应的流水线操作。也就是说，在本技术的技术方案中，可以根据工作人员触发gitee代码仓库的事件的类型，对待处理的应用代码执行对应的流水线操作。支持将多步骤工作流建模为一系列任务或者使用有向无环图描述任务之间的依赖关系，无需复杂的软件配置，轻量级，使用方便。而在现有技术中，对于多模块项目的开发，参与团队人员较多，跨职能协作较多，信息不透明，协作效率不高；而且产品发布规范性差，测试环境和生产环境使用镜像管理混乱。因此，和现有技术相比，本技术实施例提出的devops实现方法、装置、电子设备及存储介质，可以有效地保证devops落地实施，从而可以使得构建、测试、发布软件能够更加地快捷、频繁和可靠；并且，本技术实施例的技术方案实现简单方便、便于普及，适用范围更广。
附图说明
20.图1为本技术实施例提供的devops实现方法的第一流程示意图；
21.图2为本技术实施例提供的devops实现方法的第二流程示意图；
22.图3为本技术实施例提供的devops实现方法的第三流程示意图；
23.图4为本技术实施例提供的devops实现方法的第四流程示意图；
24.图5为本技术实施例提供的devops实现方法的第五流程示意图；
25.图6为本技术实施例提供的devops实现装置的结构示意图；
26.图7为本技术实施例提供的电子设备的结构示意图。
具体实施方式
27.下面结合附图和实施例对本技术作进一步的详细说明。可以理解的是，此处所描述的具体实施例仅仅用于解释本技术，而非对本技术的限定。另外还需要说明的是，为了便
于描述，附图中仅示出了与本技术相关的部分而非全部结构。
28.实施例一
29.图1为本技术实施例提供的devops实现方法的第一流程示意图，该方法可以由devops实现装置或者电子设备来执行，该装置或者电子设备可以由软件和/或硬件的方式实现，该装置或者电子设备可以集成在任何具有网络通信功能的智能设备中。如图1所示，devops实现方法可以包括以下步骤：
30.s101、接收webhook发送的gitee webhook post消息；其中，giteewebhook post消息包括以下其中之一：push hook消息、tag push hook消息、 pull request hook消息。
31.在本步骤中，电子设备可以通过argo事件驱动软件接收webhook发送的 gitee webhook post消息；其中，gitee webhook post消息包括以下其中之一：push hook、tag push hook、pull request hook。本技术实施例中电子设备可以通过webhook监听工作人员触发gitee代码仓库的事件；其中，工作人员触发 gitee代码仓库的事件的类型可以包括以下三种：工作人员向gitee代码仓库中提交应用代码、工作人员在gitee代码仓库中的至少一个应用代码中标记版本、工作人员将子分支中的应用代码合并到主干分支中。具体地，当webhook监听到工作人员向gitee代码仓库中提交应用代码时，webhook可以向argo事件驱动软件发送push hook消息；当webhook监听到工作人员在gitee代码仓库中的至少一个应用代码中标记版本时，webhook可以向argo事件驱动软件发送 tag push hook消息；当webhook监听到工作人员将子分支中的应用代码合并到主干分支中时，webhook可以向argo事件驱动软件发送pull request hook消息。
32.s102、对gitee webhook post消息进行解析，得到工作人员触发gitee代码仓库的事件的类型；其中，工作人员触发gitee代码仓库的事件的类型包括：工作人员向gitee代码仓库中提交应用代码、工作人员在gitee代码仓库中的至少一个应用代码中标记版本、工作人员将子分支中的应用代码合并到主干分支中。
33.在本步骤中，电子设备可以通过argo事件驱动软件对gitee webhook post 消息进行解析，得到工作人员触发gitee代码仓库的事件的类型；其中，工作人员触发gitee代码仓库的事件的类型包括：工作人员向gitee代码仓库中提交应用代码、工作人员在gitee代码仓库中的至少一个应用代码中标记版本、工作人员将子分支中的应用代码合并到主干分支中。具体地，电子设备可以通过argo 事件驱动软件对gitee webhook post消息进行解析，解析出各类关键字段；然后根据消息头筛选出工作人员触发gitee代码仓库的事件的类型。
34.s103、根据工作人员触发gitee代码仓库的事件的类型，对待处理的应用代码执行对应的流水线操作。
35.在本步骤中，电子设备可以根据工作人员触发gitee代码仓库的事件的类型，通过argo事件驱动软件对待处理的应用代码执行对应的流水线操作。具体地，若工作人员触发gitee代码仓库的事件的类型为工作人员向gitee代码仓库中提交应用代码，则对待处理的应用代码执行dev类型的流水线操作；若工作人员触发gitee代码仓库的事件的类型为工作人员在gitee代码仓库中的至少一个应用代码中标记版本，则对待处理的应用代码执行release类型的流水线操作；若工作人员触发gitee代码仓库的事件的类型为工作人员将子分支中的应用代码合并到主干分支中，则对待处理的应用代码执行pr类型的流水线操作。
prometheus和grafana。
43.在本技术的具体实施例中，在执行本技术实施例提供的devops实现方法之前，还需要预先做好以下准备工作：1、准备gitee repo：argo流水线、应用代码、kubernetes产品部署资源清单三部分；2、安装和配置sonarqube代码检查服务器并配置c++检查规则；3、安装和配置harbor docker镜像私有仓库并创建不同的库，用于存储开发版本和发布版本的镜像；4、配置机器人，用于接收argo流水线结果通知；5、安装argo events事件驱动框架并部署devops ci 和cd流水线所需的事件源、传感器和触发器；6、安装和配置argocd客户端和服务器端，创建argocd应用；7、在gitee代码仓库中创建webhook并配置应用源码仓库的webhook；8、自动触发argo工作流：gitee代码仓库上修改及提交代码、打标签或提交合并请求，webhook触发argo ci/cd流水线工作流。
44.本技术实施例提出的devops实现方法，先接收webhook发送的giteewebhook post消息；然后对gitee webhook post消息进行解析，得到工作人员触发gitee代码仓库的事件的类型；再根据工作人员触发gitee代码仓库的事件的类型，对待处理的应用代码执行对应的流水线操作。也就是说，在本技术的技术方案中，可以根据工作人员触发gitee代码仓库的事件的类型，对待处理的应用代码执行对应的流水线操作。支持将多步骤工作流建模为一系列任务或者使用有向无环图描述任务之间的依赖关系，无需复杂的软件配置，轻量级，使用方便。而在现有技术中，对于多模块项目的开发，参与团队人员较多，跨职能协作较多，信息不透明，协作效率不高；而且产品发布规范性差，测试环境和生产环境使用镜像管理混乱。因此，和现有技术相比，本技术实施例提出的devops实现方法，可以有效地保证devops落地实施，从而可以使得构建、测试、发布软件能够更加地快捷、频繁和可靠；并且，本技术实施例的技术方案实现简单方便、便于普及，适用范围更广。
45.实施例三
46.图3为本技术实施例提供的devops实现方法的第三流程示意图。基于上述技术方案进一步优化与扩展，并可以与上述各个可选实施方式进行结合。如图3所示，devops实现方法可以包括以下步骤：
47.s301、接收webhook发送的gitee webhook post消息；其中，giteewebhook post消息包括以下其中之一：push hook消息、tag push hook消息、pull request hook消息。
48.s302、对gitee webhook post消息进行解析，得到工作人员触发gitee代码仓库的事件的类型；其中，工作人员触发gitee代码仓库的事件的类型包括：工作人员向gitee代码仓库中提交应用代码、工作人员在gitee代码仓库中的至少一个应用代码中标记版本、工作人员将子分支中的应用代码合并到主干分支中。
49.s303、若工作人员触发gitee代码仓库的事件的类型为工作人员向gitee代码仓库中提交应用代码，则在gitee代码仓库中提取待处理的应用代码，并对待处理的应用代码进行dev版本测试，得到待处理的应用代码的dev版本测试结果。
50.s304、若待处理的应用代码的dev版本测试结果表示待处理的应用代码通过dev版本测试，则将待处理的应用代码的dev版本镜像推送到容器云平台内部的harbor服务器对应的dev开发库中。
51.s305、基于dev开发库更新gitee代码仓库中的产品部署配置。
52.s306、根据更新后的产品部署配置从harbor镜像中心获取最新的dev版本的应用
镜像，将最新的dev版本的应用镜像部署到容器云平台并执行相应的自动化测试。
53.在本技术的具体实施例中，若工作人员触发gitee代码仓库的事件的类型为工作人员向gitee代码仓库中提交应用代码，则先从gitee代码仓库中拉取应用代码，使用sonarqube进行静态代码检查，并使用bazel编译和单元测试，然后构建dev版本镜像，执行自动化测试，通过测试后将镜像推送到容器云平台内部的harbor服务器对应的dev开发库中，最后再更新gitee代码仓库中的产品部署配，argocd服务器检测到部署文件的变化，根据新的部署配置从其内部的harbor镜像中心获取最新的应用镜像，然后部署到容器云平台并执行相应的自动化测试。
54.本技术实施例提出的devops实现方法，先接收webhook发送的giteewebhook post消息；然后对gitee webhook post消息进行解析，得到工作人员触发gitee代码仓库的事件的类型；再根据工作人员触发gitee代码仓库的事件的类型，对待处理的应用代码执行对应的流水线操作。也就是说，在本技术的技术方案中，可以根据工作人员触发gitee代码仓库的事件的类型，对待处理的应用代码执行对应的流水线操作。支持将多步骤工作流建模为一系列任务或者使用有向无环图描述任务之间的依赖关系，无需复杂的软件配置，轻量级，使用方便。而在现有技术中，对于多模块项目的开发，参与团队人员较多，跨职能协作较多，信息不透明，协作效率不高；而且产品发布规范性差，测试环境和生产环境使用镜像管理混乱。因此，和现有技术相比，本技术实施例提出的devops实现方法，可以有效地保证devops落地实施，从而可以使得构建、测试、发布软件能够更加地快捷、频繁和可靠；并且，本技术实施例的技术方案实现简单方便、便于普及，适用范围更广。
55.实施例四
56.图4为本技术实施例提供的devops实现方法的第四流程示意图。基于上述技术方案进一步优化与扩展，并可以与上述各个可选实施方式进行结合。如图4所示，devops实现方法可以包括以下步骤：
57.s401、接收webhook发送的gitee webhook post消息；其中，giteewebhook post消息包括以下其中之一：push hook消息、tag push hook消息、 pull request hook消息。
58.s402、对gitee webhook post消息进行解析，得到工作人员触发gitee代码仓库的事件的类型；其中，工作人员触发gitee代码仓库的事件的类型包括：工作人员向gitee代码仓库中提交应用代码、工作人员在gitee代码仓库中的至少一个应用代码中标记版本、工作人员将子分支中的应用代码合并到主干分支中。
59.s403、若工作人员触发gitee代码仓库的事件的类型为工作人员在gitee代码仓库中的至少一个应用代码中标记版本，则在gitee代码仓库中提取待处理的应用代码，并对待处理的应用代码进行release版本测试，得到待处理的应用代码的release版本测试结果。
60.s404、若待处理的应用代码的release版本测试结果表示待处理的应用代码通过release版本测试，则将待处理的应用代码的release版本镜像推送至容器云平台内部的harbor服务器的release发布库中。
61.s405、基于release发布库更新gitee代码仓库中的产品部署配置。
62.s406、根据更新后的产品部署配置从harbor镜像中心获取最新的release 版本的应用镜像，将最新的release版本的应用镜像部署到容器云平台并执行相应的自动化测试。
63.在本技术的具体实施例中，若工作人员触发gitee代码仓库的事件的类型为工作
人员在gitee代码仓库中的至少一个应用代码中标记版本，则电子设备可以通过argo事件驱动软件先从gitee代码仓库中拉取应用代码，使用sonarqube进行静态代码检查，并使用bazel编译和单元测试，然后构建release版本镜像，将镜像推送至harbor服务器的临时库中，并将临时镜像部署到测试环境，执行集成测试和系统测试，通过测试后将镜像推送到harbor的release发布库中，最后再更新gitee代码仓库中的产品部署配置，在发布镜像成功后升级bumpversion版本，argocd服务器检测到部署文件的变化，根据新的部署配置从其内部的harbor镜像中心获取最新的应用镜像，然后部署到容器云平台并执行相应的自动化测试。本技术实施例中的release版本镜像标签以bumpversion版本号(阿拉伯数字递增，例如0.0.1，0.0.2，
…
)命名：${harbor-server}/release/${imagename}:${bumpversion}。
64.本技术实施例提出的devops实现方法，先接收webhook发送的giteewebhookpost消息；然后对giteewebhookpost消息进行解析，得到工作人员触发gitee代码仓库的事件的类型；再根据工作人员触发gitee代码仓库的事件的类型，对待处理的应用代码执行对应的流水线操作。也就是说，在本技术的技术方案中，可以根据工作人员触发gitee代码仓库的事件的类型，对待处理的应用代码执行对应的流水线操作。支持将多步骤工作流建模为一系列任务或者使用有向无环图描述任务之间的依赖关系，无需复杂的软件配置，轻量级，使用方便。而在现有技术中，对于多模块项目的开发，参与团队人员较多，跨职能协作较多，信息不透明，协作效率不高；而且产品发布规范性差，测试环境和生产环境使用镜像管理混乱。因此，和现有技术相比，本技术实施例提出的devops实现方法，可以有效地保证devops落地实施，从而可以使得构建、测试、发布软件能够更加地快捷、频繁和可靠；并且，本技术实施例的技术方案实现简单方便、便于普及，适用范围更广。
65.实施例五
66.图5为本技术实施例提供的devops实现方法的第五流程示意图。基于上述技术方案进一步优化与扩展，并可以与上述各个可选实施方式进行结合。如图5所示，devops实现方法可以包括以下步骤：
67.s501、接收webhook发送的giteewebhookpost消息；其中，giteewebhookpost消息包括以下其中之一：pushhook消息、tagpushhook消息、pullrequesthook消息。
68.s502、对giteewebhookpost消息进行解析，得到工作人员触发gitee代码仓库的事件的类型；其中，工作人员触发gitee代码仓库的事件的类型包括：工作人员向gitee代码仓库中提交应用代码、工作人员在gitee代码仓库中的至少一个应用代码中标记版本、工作人员将子分支中的应用代码合并到主干分支中。
69.s503、若工作人员触发gitee代码仓库的事件的类型为工作人员将子分支中的应用代码合并到主干分支中，则获取pullrequesthook消息相关联的headcommit。
70.s504、基于pullrequesthook消息相关联的headcommit，对待处理的应用代码执行pr类型的流水线操作。
71.在本技术的具体实施例中，若工作人员触发gitee代码仓库的事件的类型为工作人员将子分支中的应用代码合并到主干分支中，由于开发者没有主干分支的写权限，写权限是被严格控制的，因此必须经过pullrequest方式合入代码。在相应的分支研发并自测完成后，通过giteeweb界面提交一个pullrequest请求将这些代码合入到主干分支，触
发pr类型流水线的执行，因为该合并所包含的所有提交都已经经过dev类型的流水线的验证，因此可以将最后一次提交headcommit的流水线结果评论取出，并添加到该次pr的评论中，pr相关人(例如审核人员，测试人员等)可以参考评论的内容判断是否允许合入代码，当代码合入主干分支后，又将自动触发dev类型的流水线流程。
72.本技术使用云原生时代诞生的流水线框架argo工作流流水线，工作流的每一步都是一个容器，支持将多步骤工作流建模为一系列任务或者使用有向无环图(dag)描述任务之间的依赖关系，在kubernetes上运行ci/cdpipeline，无需复杂的软件配置，轻量级，使用方便；将argo流水线分级为主流水线和子流水线，监听gitee仓库webhook事件，根据webhook事件类型，自动触发不同的流水线，隔离了dev类型和release发布类型镜像的制作过程，只有经过特定的部署验证流程的镜像才能进入harbor的release发布库中；使用argocd拉式自动部署方式：目前大多数的ci/cd工具都使用基于推送的模型，从ci系统开始，通过一系列构建测试等最终生成镜像，最后手动使用“kubectl”将任何更改推送至kubernetes集群，这样做会将集群的用户和密码等公布出去，虽然可以采用一些有效措施保护ci/cd脚本和命令，但这些操作是在集群外部非可信区工作的，会给系统安全带来潜在的风险，而argocd使用集群内部的deployoperator，集群凭据不会在生产环境之外公开。
73.本技术实施例提出的devops实现方法，先接收webhook发送的giteewebhookpost消息；然后对giteewebhookpost消息进行解析，得到工作人员触发gitee代码仓库的事件的类型；再根据工作人员触发gitee代码仓库的事件的类型，对待处理的应用代码执行对应的流水线操作。也就是说，在本技术的技术方案中，可以根据工作人员触发gitee代码仓库的事件的类型，对待处理的应用代码执行对应的流水线操作。支持将多步骤工作流建模为一系列任务或者使用有向无环图描述任务之间的依赖关系，无需复杂的软件配置，轻量级，使用方便。而在现有技术中，对于多模块项目的开发，参与团队人员较多，跨职能协作较多，信息不透明，协作效率不高；而且产品发布规范性差，测试环境和生产环境使用镜像管理混乱。因此，和现有技术相比，本技术实施例提出的devops实现方法，可以有效地保证devops落地实施，从而可以使得构建、测试、发布软件能够更加地快捷、频繁和可靠；并且，本技术实施例的技术方案实现简单方便、便于普及，适用范围更广。
74.实施例六
75.图6为本技术实施例提供的devops实现装置的结构示意图。如图6所示，所述devops实现装置包括：接收模块601、解析模块602和执行模块603；其中，
76.所述接收模块601，用于接收webhook发送的giteewebhookpost消息；其中，所述giteewebhookpost消息包括以下其中之一：pushhook消息、tagpushhook消息、pullrequesthook消息；
77.所述解析模块602，用于对所述giteewebhookpost消息进行解析，得到工作人员触发gitee代码仓库的事件的类型；其中，所述工作人员触发gitee代码仓库的事件的类型包括：所述工作人员向所述gitee代码仓库中提交应用代码、所述工作人员在所述gitee代码仓库中的至少一个应用代码中标记版本、所述工作人员将子分支中的应用代码合并到主干分支中；
78.所述执行模块603，用于根据所述工作人员触发gitee代码仓库的事件的类型，对待处理的应用代码执行对应的流水线操作。
79.进一步地，所述执行模块603，具体用于若所述工作人员触发gitee代码仓库的事件的类型为所述工作人员向所述gitee代码仓库中提交应用代码，则对所述待处理的应用代码执行dev类型的流水线操作；若所述工作人员触发gitee 代码仓库的事件的类型为所述工作人员在所述gitee代码仓库中的至少一个应用代码中标记版本，则对所述待处理的应用代码执行release类型的流水线操作；若所述工作人员触发gitee代码仓库的事件的类型为所述工作人员将子分支中的应用代码合并到主干分支中，则对所述待处理的应用代码执行pr类型的流水线操作。
80.上述devops实现装置可执行本技术任意实施例所提供的方法，具备执行方法相应的功能模块和有益效果。未在本实施例中详尽描述的技术细节，可参见本技术任意实施例提供的devops实现方法。
81.实施例七
82.图7为本技术实施例提供的电子设备的结构示意图。图7示出了适于用来实现本技术实施方式的示例性电子设备的框图。图7显示的电子设备12仅仅是一个示例，不应对本技术实施例的功能和使用范围带来任何限制。
83.如图7所示，电子设备12以通用计算设备的形式表现。电子设备12的组件可以包括但不限于：一个或者多个处理器或者处理单元16，系统存储器28，连接不同系统组件(包括系统存储器28和处理单元16)的总线18。
84.总线18表示几类总线结构中的一种或多种，包括存储器总线或者存储器控制器，外围总线，图形加速端口，处理器或者使用多种总线结构中的任意总线结构的局域总线。举例来说，这些体系结构包括但不限于工业标准体系结构(isa) 总线，微通道体系结构(mac)总线，增强型isa总线、视频电子标准协会(vesa) 局域总线以及外围组件互连(pci)总线。
85.电子设备12典型地包括多种计算机系统可读介质。这些介质可以是任何能够被电子设备12访问的可用介质，包括易失性和非易失性介质，可移动的和不可移动的介质。
86.系统存储器28可以包括易失性存储器形式的计算机系统可读介质，例如随机存取存储器(ram)30和/或高速缓存存储器32。电子设备12可以进一步包括其它可移动/不可移动的、易失性/非易失性计算机系统存储介质。仅作为举例，存储系统34可以用于读写不可移动的、非易失性磁介质(图7未显示，通常称为“硬盘驱动器”)。尽管图7中未示出，可以提供用于对可移动非易失性磁盘 (例如“软盘”)读写的磁盘驱动器，以及对可移动非易失性光盘(例如cd-rom， dvd-rom或者其它光介质)读写的光盘驱动器。在这些情况下，每个驱动器可以通过一个或者多个数据介质接口与总线18相连。存储器28可以包括至少一个程序产品，该程序产品具有一组(例如至少一个)程序模块，这些程序模块被配置以执行本技术各实施例的功能。
87.具有一组(至少一个)程序模块42的程序/实用工具40，可以存储在例如存储器28中，这样的程序模块42包括但不限于操作系统、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。程序模块42通常执行本技术所描述的实施例中的功能和/ 或方法。
88.电子设备12也可以与一个或多个外部设备14(例如键盘、指向设备、显示器24等)通信，还可与一个或者多个使得用户能与该电子设备12交互的设备通信，和/或与使得该电子设备12能与一个或多个其它计算设备进行通信的任何设备(例如网卡，调制解调器等等)
通信。这种通信可以通过输入/输出(i/o) 接口22进行。并且，电子设备12还可以通过网络适配器20与一个或者多个网络(例如局域网(lan)，广域网(wan)和/或公共网络，例如因特网)通信。如图所示，网络适配器20通过总线18与电子设备12的其它模块通信。应当明白，尽管图7中未示出，可以结合电子设备12使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、raid 系统、磁带驱动器以及数据备份存储系统等。
89.处理单元16通过运行存储在系统存储器28中的程序，从而执行各种功能应用以及数据处理，例如实现本技术实施例所提供的devops实现方法。
90.实施例八
91.本技术实施例提供了一种计算机存储介质。
92.本技术实施例的计算机可读存储介质，可以采用一个或多个计算机可读的介质的任意组合。计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机存取存储器(ram)、只读存储器(rom)、可擦式可编程只读存储器(eprom或闪存)、光纤、便携式紧凑磁盘只读存储器(cd-rom)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本文件中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。
93.计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。
94.计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括——但不限于无线、电线、光缆、rf等等，或者上述的任意合适的组合。
95.可以以一种或多种程序设计语言或其组合来编写用于执行本技术操作的计算机程序代码，所述程序设计语言包括面向对象的程序设计语言—诸如java、 smalltalk、c++，还包括常规的过程式程序设计语言—诸如“c”语言或类似的程序设计语言。程序代码可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中，远程计算机可以通过任意种类的网络——包括局域网(lan)或广域网 (wan)—连接到用户计算机，或者，可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。
96.注意，上述仅为本技术的较佳实施例及所运用技术原理。本领域技术人员会理解，本技术不限于这里所述的特定实施例，对本领域技术人员来说能够进行各种明显的变化、重新调整和替代而不会脱离本技术的保护范围。因此，虽然通过以上实施例对本技术进行了较为详细的说明，但是本技术不仅仅限于以上实施例，在不脱离本技术构思的情况下，还可以包括更多其他等效实施例，而本技术的范围由所附的权利要求范围决定。