程序文件的管理方法及装置、存储介质、电子设备与流程

1.本公开涉及计算机技术领域，尤其涉及一种程序文件的管理方法与程序文件的管理装置、计算机可读存储介质及电子设备。


背景技术：

2.容器内的软件或应用就可以在任何环境和任何基础架构上一致地移动和运行，不受该环境或基础架构的操作系统影响。以python为例，python程序运行过程中，除自带的基础模块外，往往需要大量依赖第三方的包。对于第三方包的灵活使用给开发工作带来了很多便利。但是，项目中对第三方包的管理方式和进程容器化部署的矛盾在容器化过程中逐渐显现，原有的包部署和管理方式不再适用。
3.现阶段项目主要的python包管理方式主要分为两种。一种是基于自研应用框架的进程，python包统一在物理机进行部署，所有进程共用python包。另一种是基于flask框架部署的http(hyper text transfer protocol，超文本传输协议)服务进程，对每个服务独立创建、部署虚拟环境运行，服务独享第三方python包。但是，第一种方式不具有降低维护代价的优势，并且，当运行环境跟随容器奖项构建而隔离之后，该方案显然不适合容器化后的部署和运行等一系列的流程。第二种方式耗费的时间成本过高，也会增加应用程序维护的工作量。
4.鉴于此，本领域亟需开发一种新的程序文件的管理方法及装置。
5.需要说明的是，在上述背景技术部分公开的信息仅用于加强对本公开的背景的理解，因此可以包括不构成对本领域普通技术人员已知的现有技术的信息。


技术实现要素：

6.本公开的目的在于提供一种程序文件的管理方法、程序文件的管理装置、计算机可读存储介质及电子设备，进而至少在一定程度上克服由于相关技术的限制而导致的程序包管理效果不佳的技术问题。
7.本公开的其他特性和优点将通过下面的详细描述变得显然，或部分地通过本公开的实践而习得。
8.根据本发明实施例的第一个方面，提供一种程序文件的管理方法，所述方法包括：
9.获取程序包的包信息以及与所述程序包对应的进程信息，并对所述进程信息进行解析处理得到更新后的所述进程信息；
10.获取当前进程的当前信息，并对所述当前信息和所述更新后的进程信息进行比较得到第一比较结果；
11.根据所述第一比较结果对所述更新后的进程信息进行剔除处理得到目标信息，以通过所述包信息和所述目标信息对所述程序包进行管理。
12.在本发明的一种示例性实施例中，在对所述进程信息进行解析处理得到更新后的所述进程信息之后，所述方法还包括：
13.存储所述包信息和所述更新后的进程信息。
14.在本发明的一种示例性实施例中，所述通过所述包信息和所述目标信息对所述程序包进行管理，包括：
15.确定所述程序包的适用范围，并根据所述适用范围将所述程序包确定为通用包和自定义包；
16.通过所述包信息和所述目标信息对所述通用包或所述自定义包进行管理。
17.在本发明的一种示例性实施例中，所述通过所述包信息和所述目标信息对所述通用包或所述自定义包进行管理，包括：
18.获取所述通用包或所述自定义包的环境参数，并根据所述环境参数确定所述通用包或所述自定义包的当前环境；
19.在所述当前环境下，根据所述包信息和所述目标信息对所述通用包进行管理；
20.在所述当前环境下，根据所述包信息和所述目标信息对所述自定义包进行管理。
21.在本发明的一种示例性实施例中，所述包信息包括包名信息，所述根据所述包信息和所述目标信息对所述通用包进行管理，包括：
22.根据所述包名信息或者所述目标信息查询所述包信息，并显示所述包信息。
23.在本发明的一种示例性实施例中，在显示所述包信息之后，所述根据所述包信息和所述目标信息对所述通用包进行管理，包括：
24.基于所述目标信息，根据所述包信息对所述通用包进行配置修改得到通用配置记录，以根据所述通用配置记录更新所述通用包的所述包信息。
25.在本发明的一种示例性实施例中，所述根据所述包信息对所述通用包进行配置修改得到通用配置记录，包括：
26.新增与所述包信息对应的通用配置记录；
27.修改所述包信息得到通用配置记录；
28.删除所述包信息得到通用配置记录。
29.在本发明的一种示例性实施例中，所述当前环境包括测试环境和生产环境，
30.所述根据所述包信息和所述目标信息对所述通用包进行管理，包括：
31.根据所述测试环境和所述生产环境对所述包信息进行区分得到第一测试包信息和第一生产包信息；
32.对所述第一测试包信息和所述第一生产包信息进行比较得到第二比较结果，并根据所述第二比较结果标注所述第一测试包信息和所述第一生产包信息。
33.在本发明的一种示例性实施例中，所述对所述第一测试包信息和所述第一生产包信息进行比较得到第二比较结果，包括：
34.分别对所述第一测试包信息和所述第一生产包信息进行排序，并对排序后的所述第一测试包信息和所述第一生产包信息进行格式转换得到目标格式的所述第一测试包信息和所述第一生产包信息；
35.对所述目标格式的所述第一测试包信息和所述第一生产包信息进行比较得到第二比较结果。
36.在本发明的一种示例性实施例中，所述根据所述包信息和所述目标信息对所述通用包进行管理，包括：
37.基于所述目标信息，对所述包信息进行拼接处理得到通用文本文件。
38.在本发明的一种示例性实施例中，所述方法还包括：
39.接收所述通用文本文件的安装指令，并根据所述通用文本文件构建所述通用包的通用镜像文件。
40.在本发明的一种示例性实施例中，所述包信息包括包名信息，
41.所述根据所述包信息和所述目标信息对所述自定义包进行管理，包括：
42.获取与所述自定义包对应的服务名称信息；
43.基于所述服务名称信息，根据所述包名信息或者所述目标信息查询所述包信息，并显示所述包信息。
44.在本发明的一种示例性实施例中，所述根据所述包信息和所述目标信息对所述自定义包进行管理，包括：
45.基于所述目标信息，获取与所述自定义包对应的服务名称信息；
46.基于所述服务名称信息，基于所述服务名称信息，根据所述包信息对所述自定义包进行配置修改得到定义配置记录，以根据所述定义配置记录更新所述自定义包的所述包信息。
47.在本发明的一种示例性实施例中，所述根据所述包信息对所述自定义包进行配置修改得到定义配置记录，包括：
48.新增与所述包信息对应的定义配置记录；
49.修改所述包信息得到定义配置记录；
50.删除所述包信息得到定义配置记录。
51.在本发明的一种示例性实施例中，所述当前环境包括测试环境和生产环境，
52.所述根据所述包信息和所述目标信息对所述自定义包进行管理，包括：
53.根据所述测试环境和所述生产环境对所述包信息进行区分得到第二测试包信息和第二生产包信息，并获取与所述自定义包对应的服务名称信息；
54.基于所述服务名称信息，对所述第二测试包信息和所述第二生产包信息进行比较得到第三比较结果，并根据所述第三比较结果标注所述第二测试包信息和所述第二生产包信息。
55.在本发明的一种示例性实施例中，所述对所述第二测试包信息和所述第二生产包信息进行比较得到第三比较结果，包括：
56.分别对所述第二测试包信息和所述第二生产包信息进行排序，并对排序后的所述第二测试包信息和所述第二生产包信息进行格式转换得到目标格式的所述第二测试包信息和所述第二生产包信息；
57.对所述目标格式的所述第二测试包信息和所述第二生产包信息进行比较得到第三比较结果。
58.在本发明的一种示例性实施例中，所述包信息分为通用包信息和定义包信息，
59.所述根据所述包信息和所述目标信息对所述自定义包进行管理，包括：
60.基于所述目标信息，获取与所述自定义包对应的服务名称信息；
61.基于所述服务名称信息，对所述通用包信息和所述定义包信息进行合并得到目标包信息；
62.对所述目标包信息进行拼接处理得到定义文本文件。
63.在本发明的一种示例性实施例中，所述方法还包括：
64.接收所述定义文本文件的安装指令，并根据所述定义文本文件构建所述自定义包的定义镜像文件。
65.在本发明的一种示例性实施例中，在通过所述包信息和所述目标信息对所述程序包进行管理之后，所述方法还包括：
66.移除所述包信息。
67.根据本发明实施例的第二个方面，提供一种程序文件的管理装置，包括：
68.信息解析模块，被配置为获取程序包的包信息以及与所述程序包对应的进程信息，并对所述进程信息进行解析处理得到更新后的所述进程信息；
69.信息比较模块，被配置为获取当前进程的当前信息，并对所述当前信息和所述更新后的进程信息进行比较得到第一比较结果；
70.文件管理模块，被配置为根据所述第一比较结果对所述更新后的进程信息进行剔除处理得到目标信息，以通过所述包信息和所述目标信息对所述程序包进行管理。
71.根据本发明实施例的第三个方面，提供一种电子设备，包括：处理器和存储器；其中，存储器上存储有计算机可读指令，所述计算机可读指令被所述处理器执行时实现上述任意示例性实施例中的程序文件的管理方法。
72.根据本发明实施例的第四个方面，提供一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现上述任意示例性实施例中的程序文件的管理方法。
73.由上述技术方案可知，本公开示例性实施例中的程序文件的管理方法、程序文件的管理装置、计算机存储介质及电子设备至少具备以下优点和积极效果：
74.在本公开的示例性实施例提供的方法及装置中，获取到的程序包的包信息以及解析处理后的进程信息，有助于开发人员了解进程运行时程序包的实际引用状态，帮助开发人员区分程序包的包信息是否真正生效，提高了问题定位和追踪的效率。更进一步的，通过包信息和目标信息对程序包进行管理，能够在较小的维护成本的前提下，以一种更加灵活的方式控制不同服务的包信息，实现了对程序包进行精细化管理，降低了维护成本、维护工作量和时间成本，也为特殊版本指定和版本灰度测试等场景提供了更加便捷的解决方案。
75.应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。
附图说明
76.此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。显而易见地，下面描述中的附图仅仅是本公开的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
77.图1示意性示出本公开示例性实施例中一种程序文件的管理方法的流程示意图；
78.图2示意性示出本公开示例性实施例中管理程序包的方法的流程示意图；
79.图3示意性示出本公开示例性实施例中通过包信息和目标信息管理程序包的方法
的流程示意图；
80.图4示意性示出本公开示例性实施例中得到通用配置记录的方法的流程示意图；
81.图5示意性示出本公开示例性实施例中标注第一测试包信息和第一生产包信息的方法的流程示意图；
82.图6示意性示出本公开示例性实施例中得到第二比较结果的方法的流程示意图；
83.图7示意性示出本公开示例性实施例中显示自定义包的包信息的方法的流程示意图；
84.图8示意性示出本公开示例性实施例中得到定义配置记录的方法的流程示意图；
85.图9示意性示出本公开示例性实施例中进一步得到定义配置记录的方法的流程示意图；
86.图10示意性示出本公开示例性实施例中标注第二测试包信息和第二生产包信息的方法的流程示意图；
87.图11示意性示出本公开示例性实施例中得到第三比较结果的方法的流程示意图；
88.图12示意性示出本公开示例性实施例中得到定义文本文件的方法的流程示意图；
89.图13示意性示出本公开示例性实施例中应用场景下获取包信息和目标信息的方法的流程示意图；
90.图14示意性示出本公开示例性实施例中应用场景下对程序包进行管理的配置后台的架构示意图；
91.图15示意性示出本公开示例性实施例中应用场景下构建通用镜像文件和定义镜像文件的方法的流程示意图；
92.图16示意性示出本公开示例性实施例中一种程序文件的管理装置的结构示意图；
93.图17示意性示出本公开示例性实施例中一种用于实现程序文件的管理方法的电子设备；
94.图18示意性示出本公开示例性实施例中一种用于实现程序文件的管理方法的计算机可读存储介质。
具体实施方式
95.现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些实施方式使得本公开将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施方式中。在下面的描述中，提供许多具体细节从而给出对本公开的实施方式的充分理解。然而，本领域技术人员将意识到，可以实践本公开的技术方案而省略所述特定细节中的一个或更多，或者可以采用其它的方法、组元、装置、步骤等。在其它情况下，不详细示出或描述公知技术方案以避免喧宾夺主而使得本公开的各方面变得模糊。
96.本说明书中使用用语“一个”、“一”、“该”和“所述”用以表示存在一个或多个要素/组成部分/等；用语“包括”和“具有”用以表示开放式的包括在内的意思并且是指除了列出的要素/组成部分/等之外还可存在另外的要素/组成部分/等；用语“第一”和“第二”等仅作为标记使用，不是对其对象的数量限制。
97.此外，附图仅为本公开的示意性图解，并非一定是按比例绘制。图中相同的附图标记表示相同或类似的部分，因而将省略对它们的重复描述。附图中所示的一些方框图是功能实体，不一定必须与物理或逻辑上独立的实体相对应。
98.容器化是指将软件代码和所需的所有组件，例如库、框架和其他依赖项等打包在一起，让它们隔离在自己的“容器”中。这样，容器内的软件或应用就可以在任何环境和任何基础架构上一致地移动和运行，不受该环境或基础架构的操作系统影响。它相当于是一个功能全面、便于移植的计算环境。
99.程序的运行往往涉及第三方程序包。以python为例，python程序运行过程中，除了自带的基础模块之外，往往需要大量依赖第三方的python包。
100.对于第三方python包的灵活使用，可以有效地复用代码，避免重复开发的功能相同或相近的代码模块，减轻开发工作的负担，降低业务开发的工作量。丰富且庞杂的第三方python包给开发工作带来了很多便利，但是，项目中对第三方python包的管理方式和进程容器化部署的矛盾在容器化过程中逐渐显现，原有的包部署和管理方式不再适用。
101.具体的，出现了如下的问题：缺乏精确到进程的包信息查询，无法实时获悉进程当前使用的包及相应的版本信息；无法根据不同服务指定不同的包及版本，缺少精细化控制服务依赖的能力；对第三方python包信息的管理不便于容器镜像构建；异构的服务进程采用统一的第三方python包配置会造成一定程度的冗余，代码依赖也会变得臃肿。
102.现阶段项目主要的python包管理方式主要分为两种。基于自研应用框架的进程，python包统一在物理机进行部署，所有进程共用python包；基于flask框架部署的http服务进程，对每个服务独立创建和部署虚拟环境运行，服务独享第三方python包。
103.进程共用依赖的python包管理方式的最大好处在于直观且便利。当需要大规模更新python包版本或添加新的依赖时，只需要对关联群组中的机器执行更新第三方python包的操作就可以完成依赖的更新，不需要对每个服务都单独修改第三方包的配置。采取这种方式进行python包管理的进程，往往依赖的大部分第三方包都是相同的，这种包管理方式在维护代价和依赖精确性上取得了平衡。
104.通过建立虚拟环境的方式管理第三方python包，可以有效隔离不同服务间的运行环境。当程序依赖的第三方python包差异较大时往往需要为每个服务指定包和版本号，提供可定制的包管理方式。通过在项目代码中以requirements.txt文件的形式进行配置，将第三方python包的部署、更新融入进项目的ci/cd流程中，可以用较小的维护代价达到自定义包和版本的目的。
105.虽然两种管理方案在物理机部署的时代发挥了重要作用，解决了python包在应用进程部署和管理上的问题。但是，在应用进程推进容器化的过程中，由于部署环境、部署方式的改变以及对第三方python包管理的新需求，原有的方式在实践的过程中产生了一些亟待解决的问题。
106.对于共用python环境和第三方包的方案，容器化所带来的影响中最重要的一点是应用程序是通过镜像层的堆叠构建的，这使得第三方python包和应用程序的关系没办法维持之前的相互独立的状态，必须要在镜像构建的过程中完成对第三方python包的依赖。由于构建方式的变化，每个应用程序以及其运行环境都需要单独构建，因此该方案中共用第三方python包带来的降低维护代价的优势就不再适用。共用第三方python包的方案的重要
基础在于应用程序依赖相同的运行环境，当运行环境跟随容器奖项构建而隔离之后，该方案显然不适合容器化后的部署、运行等一系列的流程。
107.通过虚拟环境管理第三方python包的方案与应用进程容器化对python包管理的需求更为接近，但是依然不能完全符合对于服务开发和部署流程的要求。通过requirements.txt文件的形式进行配置表示不同的项目都是分散地各自管理自己的第三方python包依赖文件。如果想修改所有项目的某个第三方python包，就不得不逐一进行手动修改、触发自动构建和部署、重新上传代码文件。对于上千个应用服务来说执行一遍上述流程需要耗费大量的时间才能完成。对于构建和部署流程而言，应用代码和第三方python包配置的耦合会增加应用程序维护的工作量。
108.针对相关技术中存在的问题，本公开提出了一种程序文件的管理方法。图1示出了程序文件的管理方法的流程图，如图1所示，程序文件的管理方法至少包括以下步骤：
109.步骤s110.获取程序包的包信息以及与程序包对应的进程信息，并对进程信息进行解析处理得到更新后的所述进程信息。
110.步骤s120.获取当前进程的当前信息，并对当前信息和更新后的进程信息进行比较得到第一比较结果。
111.步骤s130.根据第一比较结果对更新后的进程信息进行剔除处理得到目标信息，以通过包信息和目标信息对程序包进行管理。
112.在本公开的示例性实施例中，获取到的程序包的包信息以及解析处理后的进程信息，有助于开发人员了解进程运行时程序包的实际引用状态，帮助开发人员区分程序包的包信息是否真正生效，提高了问题定位和追踪的效率。更进一步的，通过包信息和目标信息对程序包进行管理，能够在较小的维护成本的前提下，以一种更加灵活的方式控制不同服务的包信息，实现了对程序包进行精细化管理，降低了维护成本、维护工作量和时间成本，也为特殊版本指定和版本灰度测试等场景提供了更加便捷的解决方案。
113.下面对程序文件的管理方法的各个步骤进行详细说明。
114.在步骤s110中，获取程序包的包信息以及与程序包对应的进程信息，并对进程信息进行解析处理得到更新后的所述进程信息。
115.在本公开的示例性实施例中，程序包可以是python项目中生成的python包。
116.python项目是基于python语言研发的软件项目，技术人员在研发该python项目时确定了该python项目的代码文件、资源文件和依赖关系。
117.其中，代码文件包括python项目本身的代码内容，该代码内容为技术人员基于python项目自主研发的代码；资源文件包括python项目所对应的文件资源，例如图片资源、音频资源、视频资源和网页资源等，该资源文件为在该python项目运行时需要使用的资源；依赖关系用于指示python项目部署时所依赖的其他代码内容和/或其他资源，即该代码文件与依赖信息存在依赖关系，在后续安装python项目时除了需要代码文件，还需要依赖信息才能正常安装和运行。
118.因此，将代码文件、资源文件和依赖关系分别进行打包处理可以得到相应的python包。
119.并且，由于python程序在运行过程中除了自带的基础模块外，还需要大量依赖第三方的python包。对于第三方python包的灵活使用，可以有效地复用代码，避免重复开发功
能相同或相近的代码模块，减轻开发工作的负担，降低业务开发的工作量。丰富且庞杂的第三方python包给开发工作带来了很多的便利。
120.因此，该python包可以是指开发python项目过程中所使用的第三方python包。
121.python包等程序包的包信息可以包括python包的包名信息和版本信息，也可以包括其他信息，本示例性实施例对此不做特殊限定。
122.当程序包为python包时，在应用进程在基础框架中接入通用的python包的信息收集sdk(software development kit，软件开发工具包)，通过pkg_resources(资源收集模块)获取python包的包信息。
123.由于一个应用进程中包括多个python包，因此，可以结合获取当前应用进程的服务名、ip(internet protocol，互联网协议)地址、进程id(identity document，身份标识)、进程uuid(universally unique identifier，通用唯一识别码)和启动时间等进程信息。
124.其中，进程id可以是依据顺序确定的。举例而言，当一个服务启动10个进程时，可以按照启动时间的顺序为10个进程赋予1到10的进程id。当该服务下次启动另外10个进程时，新的10个进程依旧被赋予1-10的进程id。
125.进程uuid是唯一标识进程的随机标识。当一个服务启动10个进程时，这10个进程的进程uuid都是不同的。当该服务下次启动另外10个进程时，新的10个进程的进程uuid不仅完全不同，也和之前的10个进程uuid完全不同。
126.在获取到包信息和进程信息之后，可以对该进程信息进行解析处理。
127.举例而言，当应用进程在重启时，可以将重启的应用进程的启动时间与之前启动的应用进程的启动时间进行比较。在重启的应用进程的启动时间大于其中之前启动的应用进程的启动时间时，可以使重新启动的应用进程的进程信息将该之前启动的应用进程的进程信息进行覆盖得到更新后的进程信息。
128.除此之外，针对其他不同的进程信息，还可以有其他的解析处理的方法，本示例性实施例对此不做特殊限定。
129.在可选的实施例中，存储包信息和更新后的进程信息。
130.当对进程信息进行解析处理之后，可以将包信息和进程信息存储到数据库中进行持久化存储，为后续的其他处理流程提供数据来源。
131.其中，存储包信息和进程信息进行存储的数据库可以是mongodb数据库，也可以是其他数据库，本示例性实施例对此不做特殊限定。
132.值得说明的是，在对获取到的进程信息进行解析处理时，可以是利用数据库中存储的进程信息中的启动时间进行比较，以将数据库中存储的进程信息进行覆盖更新。
133.在步骤s120中，获取当前进程的当前信息，并对当前信息和更新后的进程信息进行比较得到第一比较结果。
134.在本公开的示例性实施例中，每隔一段时间，可以获取当前所有正在运行的应用进程的当前信息。该当前信息可以包括该应用进程的进程id和进程uuid。
135.进一步的，将该当前信息与数据库中存储的更新后的进程信息进行比较得到第一比较结果。
136.在步骤s130中，根据第一比较结果对更新后的进程信息进行剔除处理得到目标信息，以通过包信息和目标信息对程序包进行管理。
137.在本公开的示例性实施例中，当第一比较结果为在当前信息中不存在数据库中存储的更新后的某个或某些进程信息时，表明该进程信息是由于服务下线产生的失效数据，可以将更新后的进程信息中的这部分信息进行剔除处理得到有效的目标信息。
138.当第一比较结果为当前信息与数据库中存储的更新后的进程信息完全一致时，表明数据库中存储的更新后的进程信息没有冗余数据，因此，该更新后的进程信息为目标信息。
139.在得到目标信息之后，可以通过包信息和目标信息对python包等程序包进行管理。
140.在可选的实施例中，图2示出了管理程序包的方法的流程示意图，如图2所示，该方法至少包括以下步骤：在步骤s210中，确定程序包的适用范围，并根据适用范围将程序包确定为通用包和自定义包。
141.举例而言，当python包适用于所有服务时，可以确定该python包为通用包；当python包适用于一个或两个等其他数量的服务，但是不是所有服务时，可以确定该python包为自定义包。并且，自定义包是根据服务名称进行配置的。
142.在步骤s220中，通过包信息和目标信息对通用包或自定义包进行管理。
143.在可选的实施例中，图3示出了通过包信息和目标信息管理程序包的方法的流程示意图，如图3所示，该方法至少包括以下步骤：在步骤s310中，获取通用包或自定义包的环境参数，并根据环境参数确定通用包或自定义包的当前环境。
144.该环境参数可以是dv(develop)参数。一般的，通过dv参数对通用包和自定义包的应用环境进行区分。这是由于一些python包要在测试环境下应用一段时间后才能够应用在生产环境中。
145.举例而言，当dv为1时，可以确定该python包当前应用环境在测试环境中；当dv为2时，可以确定该python包当前应用环境在生产环境下。
146.进一步的，在不同的当前环境下，对通用包和自定义包进行管理。
147.在步骤s320中，在当前环境下，根据包信息和目标信息对通用包进行管理。
148.对通用包的管理可以包括查询功能。
149.在可选的实施例中，包信息包括包名信息，根据包名信息或者目标信息查询包信息，并显示包信息。
150.其中，包名信息即为通用包的名称信息。
151.因此，可以通过包名信息将应用进程中的通用包罗列出来进行模糊检索快速定位以筛选出目标的通用包的信息。
152.除此之外，还可以利用目标信息中的服务名的检索功能筛选出当前正在运行的所有进程，以方便查询每个进程的通用包的引用情况。
153.除了根据服务名之外，还可以根据包名信息以及版本号检索的方式，根据某个通用包的版本号等于、大于、小于或者是否存在等不同的查询方式筛选出当前符合条件的所有进程中通用包的版本信息的应用情况。
154.进一步的，对检索得到的包名信息、版本信息和版本号限制类型等目标信息进行展示，还可以展示其他备注信息等内容，本示例性实施例对此不做特殊限定。
155.对通用包的管理还可以包括配置修改功能。
156.在可选的实施例中，基于目标信息，根据包信息对通用包进行配置修改得到通用配置记录，以根据通用配置记录更新通用包的包信息。
157.由于目标信息表征有效的更新后的进程信息，因此可以基于该目标信息对通用包进行配置修改。
158.在可选的实施例中，图4示出了得到通用配置记录的方法的流程示意图，如图4所示，该方法至少包括以下步骤：在步骤s410中，新增与包信息对应的通用配置记录。
159.在提供包名信息、版本信息、版本号限制类型和备注信息等信息之后，可以在配置后台直接添加配置记录作为通用包的通用配置记录，并存储在数据库中。该通用配置记录中记录有对包信息对应的新增信息。
160.在步骤s420中，修改包信息得到通用配置记录。
161.在显示查询出的包信息之后，可以对查询结果进行编辑得到通用包的通用配置记录，并存储在数据库中。编辑方式可以包括修改包名信息、版本信息、版本号限制类型和备注信息等内容。
162.在步骤s430中，删除包信息得到通用配置记录。
163.在显示查询出的包信息之后，可以对查询结果进行删除得到通用配置记录。举例而言，对某个特定的包名进行删除之后可以得到通用配置记录，并从数据库中移除。
164.在本示例性实施例中，通过新增、修改和删除的编辑方式能够得到通用配置记录，为包信息的修改功能提供了多样化的实现，满足了开发人员对python等程序项目的研发需求。
165.在得到通用配置记录之后，可以按照通用配置记录更新通用包的包信息，以存储到数据库中，或从数据库中移除。
166.对通用包的管理还可以包括环境对比功能。
167.在可选的实施例中，当前环境包括测试环境和生产环境，图5示出了标注第一测试包信息和第一生产包信息的方法的流程示意图，如图5所示，该方法至少包括以下步骤：在步骤s510中，根据测试环境和生产环境对包信息进行区分得到第一测试包信息和第一生产包信息。
168.举例而言，当此时的通用包既有应用在测试环境中的python包，又有应用在生产环境中的python包时，可以根据测试环境和生产环境对通用包的包信息进行区分得到第一测试包信息和第一生产包信息。
169.在步骤s520中，对第一测试包信息和第一生产包信息进行比较得到第二比较结果，并根据第二比较结果标注第一测试包信息和第一生产包信息。
170.在可选的实施例中，图6示出了得到第二比较结果的方法的流程示意图，如图6所示，该方法至少包括以下步骤：在步骤s610中，分别对第一测试包信息和第一生产包信息进行排序，并对排序后的第一测试包信息和第一生产包信息进行格式转换得到目标格式的第一测试包信息和第一生产包信息。
171.在对第一测试包信息和第一生产包信息进行排序时，可以是按照字典序，亦即a-z的顺序进行排序得到排序后的第一测试包信息和第一生产包信息。
172.进一步的，由于在数据库中存储的第一测试包信息和第一生产包信息是以表格形式进行展示的，因此，可以将表格形式的第一测试包信息和第一生产包信息转换成json
(javascript object notation,js对象简谱)格式的第一测试包信息和第一生产包信息。
173.在步骤s620中，对目标格式的第一测试包信息和第一生产包信息进行比较得到第二比较结果。
174.在得到目标格式的第一测试包信息和第一生产包信息之后们可以进行文本比对确定第一测试包信息和第一生产包信息中不相同的配置项作为第二比较结果。
175.在本示例性实施例中，通过排序和格式转换实现对第一测试包信息和第一生产包信息的比较，为标注第一测试包信息和第一生产包信息提供了数据基础。
176.在确定第一测试包信息和第一生产包信息中不相同的配置项之后，可以将第一测试包信息和第一生产包信息中不相同的配置项标注出来，以便于开发人员对测试环境和生产环境中的第一测试包信息和第一生产包信息进行维护。
177.对通用包的管理还可以包括配置导出功能。
178.在可选的实施例中，基于目标信息，对包信息进行拼接处理得到通用文本文件。
179.由于目标信息表征有效的更新后的进程信息，因此可以基于该目标信息实现对通用包的配置导出处理。
180.由于在数据库中存储的包信息是字段格式的，因此，可以将字段格式的包信息拼接成“包名＝＝版本号”的通用文本文件。该通用文本文件可以是requirements文件。
181.当应用程序依赖时，可以使用http接口通过acttachment返回该requirements文件，亦即requirements.txt。
182.在步骤s330中，在当前环境下，根据包信息和目标信息对自定义包进行管理。
183.对自定义包的管理可以包括配置查询功能。
184.在可选的实施例中，包信息包括包名信息，图7示出了显示自定义包的包信息的方法的流程示意图，如图7所示，该方法至少包括以下步骤：在步骤s710中，获取与自定义包对应的服务名称信息。
185.由于自定义包是根据服务名称进行配置的，因此可以获取到该自定义包的服务名称信息，以在服务名称下对包信息进行管理。
186.在步骤s720中，基于服务名称信息，根据包名信息或者目标信息查询包信息，并显示包信息。
187.其中，包名信息即为自定义包的名称信息。
188.在该服务名称信息下的包信息中，通过包名信息将应用进程中的自定义包罗列出来进行模糊检索快速定位以筛选出目标的自定义包的信息。
189.除此之外，还可以利用目标信息中的服务名的检索功能筛选出当前正在运行的所有进程，以方便查询每个进程的自定义包的引用情况。
190.除了根据服务名之外，还可以根据包名信息以及版本号检索的方式，根据某个自定义包的版本号等于、大于、小于或者是否存在等不同的查询方式筛选出当前符合条件的所有进程中自定义包的版本信息的应用情况。
191.进一步的，对检索得到的包名信息、版本信息和版本号限制类型等目标信息进行展示，还可以展示其他备注信息等内容，本示例性实施例对此不做特殊限定。
192.在本示例性实施例中，通过自定义包的服务名称信息，可以实现基于包名信息或目标信息的自定义包的查询功能，发挥了自定义包的配置优势，相较于通用包的统一管理，
能够实现相同服务名称信息下的自定义包的针对性管理。
193.对自定义包的管理还可以包括配置修改功能。
194.在可选的实施例中，图8示出了得到定义配置记录的方法的流程示意图，如图8所示，该方法至少包括以下步骤：在步骤s810中，基于目标信息，获取与自定义包对应的服务名称信息。
195.由于目标信息表征有效的更新后的进程信息，因此可以基于该目标信息对自定义包进行配置修改。
196.由于自定义包是根据服务名称进行配置的，因此可以获取到该自定义包的服务名称信息，以在服务名称信息下对包信息进行管理。
197.在步骤s820中，基于服务名称信息，根据包信息对自定义包进行配置修改得到定义配置记录，以根据定义配置记录更新自定义包的包信息。
198.在该服务名称信息下的包信息中，对自定义包进行配置修改得到定义配置记录。
199.在可选的实施例中，图9示出了进一步得到定义配置记录的方法的流程示意图，如图9所示，该方法至少包括以下步骤：在步骤s910中，新增与包信息对应的定义配置记录。
200.在提供包名信息、版本信息、版本号限制类型和备注信息等信息之后，可以在配置后台直接添加配置记录作为自定义包的定义配置记录，并存储在数据库中。该定义配置记录中记录有对自定义包的包信息对应的新增信息。
201.在步骤s920中，修改包信息得到定义配置记录。
202.在显示查询出的包信息之后，可以对查询结果进行编辑得到自定义包的定义配置记录，并存储在数据库中。编辑方式可以包括修改包名信息、版本信息、版本号限制类型和备注信息等内容。
203.在步骤s930中，删除包信息得到定义配置记录。
204.在显示查询出的包信息之后，可以对查询结果进行删除得到通用配置记录。举例而言，对某个特定的包名进行删除之后可以得到定义配置记录，并从数据库中移除。
205.在本示例性实施例中，通过新增、修改和删除的编辑方式能够得到定义配置记录，为包信息的修改功能提供了多样化的实现，完善了不同python包等自定义包的编辑功能，满足了开发人员对python或其他程序项目的研发需求。
206.在得到定义配置记录之后，可以按照定义配置记录更新自定义包的包信息，以存储到数据库中，或从数据库中移除。
207.对自定义包的管理还可以包括环境对比功能。
208.在可选的实施例中，当前环境包括测试环境和生产环境，图10示出了标注第二测试包信息和第二生产包信息的方法的流程示意图，如图10所示，该方法至少包括以下步骤：在步骤s1010中，根据测试环境和生产环境对包信息进行区分得到第二测试包信息和第二生产包信息，并获取与自定义包对应的服务名称信息。
209.举例而言，当此时的自定义包包既有应用在测试环境中的python包，又有应用在生产环境中的python包时，可以根据测试环境和生产环境对自定义包的包信息进行区分得到第二测试包信息和第二生产包信息。
210.由于自定义包是根据服务名称进行配置的，因此可以获取到该自定义包的服务名称信息，以在服务名称信息下对包信息进行管理。
211.在步骤s1020中，基于服务名称信息，对第二测试包信息和第二生产包信息进行比较得到第三比较结果，并根据第三比较结果标注第二测试包信息和第二生产包信息。
212.进一步的，对该服务名称信息下的第二测试包信息和第二生产包信息进行比较得到第三比较结果。
213.在可选的实施例中，图11示出了得到第三比较结果的方法的流程示意图，如图11所示，该方法至少包括以下步骤：在步骤s1110中，分别对第二测试包信息和第二生产包信息进行排序，并对排序后的第二测试包信息和第二生产包信息进行格式转换得到目标格式的第二测试包信息和第二生产包信息。
214.在对第二测试包信息和第二生产包信息进行排序时，可以是按照字典序，亦即a-z的顺序进行排序得到排序后的第二测试包信息和第二生产包信息。
215.进一步的，由于在数据库中存储的第二测试包信息和第二生产包信息是以表格形式进行展示的，因此，可以将表格形式的第二测试包信息和第二生产包信息转换成json格式的第二测试包信息和第二生产包信息。
216.在步骤s1120中，对目标格式的第二测试包信息和第二生产包信息进行比较得到第三比较结果。
217.在得到目标格式的第二测试包信息和第二生产包信息之后们可以进行文本比对确定第二测试包信息和第二生产包信息中不相同的配置项作为第三比较结果。
218.在本示例性实施例中，通过排序和格式转换实现对第二测试包信息和第二生产包信息的比较，为标注第二测试包信息和第二生产包信息提供了数据基础。
219.在确定第二测试包信息和第二生产包信息中不相同的配置项之后，可以将第二测试包信息和第二生产包信息中不相同的配置项标注出来，以便于开发人员对测试环境和生产环境中的第二测试包信息和第二生产包信息进行维护。
220.对自定义包的管理还可以包括配置导出功能。
221.在可选的实施例中，包信息分为通用包信息和定义包信息，图12示出了得到定义文本文件的方法的流程示意图，如图12所示，该方法至少包括以下步骤：在步骤s1210中，基于目标信息，获取与自定义包对应的服务名称信息。
222.由于目标信息表征有效的更新后的进程信息，因此可以基于该目标信息实现对自定义包的配置导出处理。
223.由于自定义包是根据服务名称进行配置的，因此可以获取到该自定义包的服务名称信息，以在服务名称信息下对包信息进行管理。
224.在步骤s1220中，基于服务名称信息，对通用包信息和定义包信息进行合并得到目标包信息。
225.由于对自定义包的包信息进行导出时，可能会牵扯到通用包的包信息，因此可以获取到通用包的通用包信息和自定义包的定义包信息，以对该服务名称信息下的通用包信息和定义包信息进行合并得到目标包信息。
226.在对通用包信息和定义包信息进行合并时，可以遵循自定义包的定义包信息优先的原则。
227.具体的，可以将通用包信息和定义包信息进行比较。当通用包信息与定义包信息产生差异或者冲突时，利用定义包信息覆盖通用包信息得到目标包信息。
228.在步骤s1230中，对目标包信息进行拼接处理得到定义文本文件。
229.由于在数据库中存储的包信息是字段格式的，因此，可以将字段格式的目标包信息拼接成“包名＝＝版本号”的定义文本文件。该定义文本文件可以是requirements文件。
230.当应用程序依赖时，可以使用http接口通过acttachment返回该requirements文件，亦即requirements.txt。
231.在本示例性实施例中，通过对通用包信息和定义包信息的合并和后续的拼接处理得到定义文本文件，合并方式遵循了包信息的配置优先级，并且拼接得到的定义文本文件为后续的镜像构建提供了数据基础。
232.在生成通用文本文件或定义文本文件之后，可以触发容器基础镜像的自动构建流程，以确保可以及时更新基础镜像，满足服务进程应用最新的python包引用。
233.在可选的实施例中，接收通用文本文件的安装指令，并根据通用文本文件构建通用包的通用镜像文件。
234.该通用文本文件的安装指令可以是pip install命令。
235.举例而言，由于python项目中经常有一个requirements.txt文件，里面记录了当前程序的所有依赖包及其精确版本号。因此，通用的requirements.txt文件可以通过pip命令自动生成和安装。
236.其中，安装通用包的通用镜像文件的安装指令为pip install命令。
237.通过pip install命令安装通用配置的通用包的通用文本文件，以构建通用镜像文本，完成通用包配置的镜像层构建。
238.其中，镜像(mirroring)是一种文件存储形式，是冗余的一种类型，一个磁盘上的数据在另一个磁盘上存在一个完全相同的副本即为镜像。
239.在可选的实施例中，接收定义文本文件的安装指令，并根据定义文本文件构建自定义包的定义镜像文件。
240.该定义文本文件的安装指令可以是pip install命令。
241.由于python项目中经常有一个requirements.txt文件，里面记录了当前程序的所有依赖包及其精确版本号。因此，自定义的requirements.txt文件也可以通过pip命令自动生成和安装。
242.其中，安装通用包的定义镜像文件的安装指令为pip install命令。
243.通过pip install命令安装自定义配置的自定义包的定义文本文件，以构建定义镜像文本，完成自定义包配置的镜像层构建。
244.除了在应用进程启动时获取包信息之外，还可以在应用进程销毁时自动移除包信息。
245.在可选的实施例中，移除包信息。
246.在应用进程销毁时移除包信息能够实时更新服务进程的包版本情况，进一步提高数据的准确性，起到最终一致性检查和保证的效果。
247.下面结合一应用场景对本公开实施例中的程序文件的管理做出详细说明。
248.图13示出了应用场景下获取包信息和目标信息的方法的流程示意图，如图13所示，应用进程在基础框架中接入通用的python包的信息收集sdk，通过pkg_resources获取python包的包信息。该包信息包括包名信息和版本信息。
249.再结合应用该python包的应用进程的服务名、ip地址、进程id、进程uuid和启动时间等进程信息，向数据收集服务上报。
250.上报的包信息和进程信息的收集和记录采用web(world wide web，全球广域网)服务的形式。当数据收集服务接收到应用程序发送的包信息和进程信息之后，可以对进程信息进行解析处理。
251.举例而言，当应用进程在重启时，可以将重启的应用进程的启动时间与之前启动的应用进程的启动时间进行比较。在重启的应用进程的启动时间大于其中之前启动的应用进程的启动时间时，可以使重新启动的应用进程的进程信息将该之前启动的应用进程的进程信息进行覆盖得到更新后的进程信息。
252.在解析处理得到更新后的进程信息之后，可以将更新后的进程信息存储到mongodb数据库中进行持久化，为后续的其他模块提供数据来源。
253.除此之外，数据收集服务也可以直接提供数据查询的解决方案，让数据查询后台直接访问数据收集服务，使数据查询后台对数据库解耦，以在数据库迁移的情况下减少维护成本。
254.除了数据收集服务之外，还部署了定时任务，用于检查数据库中的包信息的时效性。
255.每隔一段时间，可以获取当前所有正在运行的应用进程的当前信息。该当前信息可以包括该应用进程的进程id和进程uuid。
256.进一步的，将该当前信息与数据库中存储的更新后的进程信息进行比较得到第一比较结果。
257.当第一比较结果为在当前信息中不存在数据库中存储的更新后的某个或某些进程信息时，表明该进程信息是由于服务下线产生的失效数据，可以将更新后的进程信息中的这部分信息进行剔除处理得到有效的目标信息。
258.当第一比较结果为当前信息与数据库中存储的更新后的进程信息完全一致时，表明数据库中存储的更新后的进程信息没有冗余数据，因此，该更新后的进程信息为目标信息。
259.除此之外，数据查询后台还提供了对数据库的第三方python包的包信息展示和检索的功能。数据查询后台会展示所有正在运行的进程的详细目标信息，例如ip、进程id和启动时间等。并且，列出每个进程所依赖的python包的包信息。对单个进程的第三方python包列表可以通过包名信息进行模糊检索快速定位，并筛选出目标的python包的信息。对于所有进程列表提供的根据服务名称的检索功能，可以筛选当前正在运行的所有进程，方便查询每个进程的python包的引用情况。除了根据服务名定位之外，还提供了包名信息和版本号检索的方式，可以根据某个python包的版本号等于、大于、小于或是否存在等不同的方式，筛选出当前符合条件的所有进程，以及对应的python包的版本应用情况。
260.图14示出了应用场景下对程序包进行管理的配置后台的架构示意图，如图14所示，该配置后台架构包括数据库和配置后台。数据库中包括测试环境通用配置、生产环境通用配置、测试环境服务配置和生产环境服务配置。配置后台提供了配置查询、配置修改、环境对比和导出配置四部分功能。
261.当程序包为python包时，确定python包的适用范围，并根据适用范围将python包
确定为通用包和自定义包。
262.当python包适用于所有服务时，可以确定该python包为通用包；当python包适用于一个或两个等其他数量的服务，但是不是所有服务时，可以确定该python包为自定义包。并且，自定义包是根据服务名称进行配置的。
263.通过包信息和目标信息对通用包或自定义包进行管理。
264.获取通用包或自定义包的环境参数，并根据环境参数确定通用包或自定义包的当前环境。
265.该环境参数可以是dv参数。一般的，通过dv参数对通用包和自定义包的应用环境进行区分。这是由于一些python包要在测试环境下应用一段时间后才能够应用在生产环境中。
266.举例而言，当dv为1时，可以确定该python包当前应用环境在测试环境中；当dv为2时，可以确定该python包当前应用环境在生产环境下。
267.进一步的，在不同的当前环境下，对通用包和自定义包进行管理。
268.在当前环境下，根据包信息和目标信息对通用包进行管理。
269.对通用包的管理可以包括查询功能。
270.根据包名信息或者目标信息查询包信息，并显示包信息。
271.其中，包名信息即为通用包的名称信息。
272.因此，可以通过包名信息将应用进程中的通用包罗列出来进行模糊检索快速定位以筛选出目标的通用包的信息。
273.除此之外，还可以利用目标信息中的服务名的检索功能筛选出当前正在运行的所有进程，以方便查询每个进程的通用包的引用情况。
274.除了根据服务名之外，还可以根据包名信息以及版本号检索的方式，根据某个通用包的版本号等于、大于、小于或者是否存在等不同的查询方式筛选出当前符合条件的所有进程中通用包的版本信息的应用情况。
275.进一步的，对检索得到的包名信息、版本信息和版本号限制类型等目标信息进行展示，还可以展示其他备注信息等内容，本示例性实施例对此不做特殊限定。
276.对通用包的管理还可以包括配置修改功能。
277.根据包信息对通用包进行配置修改得到通用配置记录，以根据通用配置记录更新通用包的包信息。
278.新增与包信息对应的通用配置记录。
279.在提供包名信息、版本信息、版本号限制类型和备注信息等信息之后，可以在配置后台直接添加配置记录作为通用包的通用配置记录，并存储在数据库中。该通用配置记录中记录有对包信息对应的新增信息。
280.修改包信息得到通用配置记录。
281.在显示查询出的包信息之后，可以对查询结果进行编辑得到通用包的通用配置记录，并存储在数据库中。编辑方式可以包括修改包名信息、版本信息、版本号限制类型和备注信息等内容。
282.删除包信息得到通用配置记录。
283.在显示查询出的包信息之后，可以对查询结果进行删除得到通用配置记录。举例
而言，对某个特定的包名进行删除之后可以得到通用配置记录，并从数据库中移除。
284.在得到通用配置记录之后，可以按照通用配置记录更新通用包的包信息，以存储到数据库中，或从数据库中移除。
285.对通用包的管理还可以包括环境对比管理。
286.根据测试环境和生产环境对包信息进行区分得到第一测试包信息和第一生产包信息。
287.当此时的通用包既有应用在测试环境中的python包，又有应用在生产环境中的python包时，可以根据测试环境和生产环境对通用包的包信息进行区分得到第一测试包信息和第一生产包信息。
288.对第一测试包信息和第一生产包信息进行比较得到第二比较结果，并根据第二比较结果标注第一测试包信息和第一生产包信息。
289.分别对第一测试包信息和第一生产包信息进行排序，并对排序后的第一测试包信息和第一生产包信息进行格式转换得到目标格式的第一测试包信息和第一生产包信息。
290.在对第一测试包信息和第一生产包信息进行排序时，可以是按照字典序，亦即a-z的顺序进行排序得到排序后的第一测试包信息和第一生产包信息。
291.进一步的，由于在数据库中存储的第一测试包信息和第一生产包信息是以表格形式进行展示的，因此，可以将表格形式的第一测试包信息和第一生产包信息转换成json格式的第一测试包信息和第一生产包信息。
292.对目标格式的第一测试包信息和第一生产包信息进行比较得到第二比较结果。
293.在得到目标格式的第一测试包信息和第一生产包信息之后们可以进行文本比对确定第一测试包信息和第一生产包信息中不相同的配置项作为第二比较结果。
294.在确定第一测试包信息和第一生产包信息中不相同的配置项之后，可以将第一测试包信息和第一生产包信息中不相同的配置项标注出来，以便于开发人员对测试环境和生产环境中的第一测试包信息和第一生产包信息进行维护。
295.对通用包的管理还可以包括配置导出功能。
296.对包信息进行拼接处理得到通用文本文件。
297.由于在数据库中存储的包信息是字段格式的，因此，可以将字段格式的包信息拼接成“包名＝＝版本号”的通用文本文件。该通用文本文件可以是requirements文件。
298.当应用程序依赖时，可以使用http接口通过acttachment返回该requirements文件，亦即requirements.txt。
299.另一方面，对自定义包的管理可以包括配置查询功能。
300.获取与自定义包对应的服务名称信息。
301.由于自定义包是根据服务名称进行配置的，因此可以获取到该自定义包的服务名称信息，以在服务名称下对包信息进行管理。
302.基于服务名称信息，根据包名信息或者目标信息查询包信息，并显示包信息。
303.其中，包名信息即为自定义包的名称信息。
304.在该服务名称信息下的包信息中，通过包名信息将应用进程中的自定义包罗列出来进行模糊检索快速定位以筛选出目标的自定义包的信息。
305.除此之外，还可以利用目标信息中的服务名的检索功能筛选出当前正在运行的所
有进程，以方便查询每个进程的自定义包的引用情况。
306.除了根据服务名之外，还可以根据包名信息以及版本号检索的方式，根据某个自定义包的版本号等于、大于、小于或者是否存在等不同的查询方式筛选出当前符合条件的所有进程中自定义包的版本信息的应用情况。
307.进一步的，对检索得到的包名信息、版本信息和版本号限制类型等目标信息进行展示，还可以展示其他备注信息等内容，本示例性实施例对此不做特殊限定。
308.对自定义包的管理还可以包括配置修改功能。
309.获取与自定义包对应的服务名称信息。
310.由于自定义包是根据服务名称进行配置的，因此可以获取到该自定义包的服务名称信息，以在服务名称信息下对包信息进行管理。
311.基于服务名称信息，根据包信息对自定义包进行配置修改得到定义配置记录，以根据定义配置记录更新自定义包的包信息。
312.在该服务名称信息下的包信息中，对自定义包进行配置修改得到定义配置记录。
313.新增与包信息对应的定义配置记录。
314.在提供包名信息、版本信息、版本号限制类型和备注信息等信息之后，可以在配置后台直接添加配置记录作为自定义包的定义配置记录，并存储在数据库中。该定义配置记录中记录有对自定义包的包信息对应的新增信息。
315.修改包信息得到定义配置记录。
316.在显示查询出的包信息之后，可以对查询结果进行编辑得到自定义包的定义配置记录，并存储在数据库中。编辑方式可以包括修改包名信息、版本信息、版本号限制类型和备注信息等内容。
317.删除包信息得到定义配置记录。
318.在显示查询出的包信息之后，可以对查询结果进行删除得到通用配置记录。举例而言，对某个特定的包名进行删除之后可以得到定义配置记录，并从数据库中移除。
319.在得到定义配置记录之后，可以按照定义配置记录更新自定义包的包信息，以存储到数据库中，或从数据库中移除。
320.对自定义包的管理还可以包括环境对比功能。
321.根据测试环境和生产环境对包信息进行区分得到第二测试包信息和第二生产包信息，并获取与自定义包对应的服务名称信息。
322.当此时的自定义包包既有应用在测试环境中的python包，又有应用在生产环境中的python包时，可以根据测试环境和生产环境对自定义包的包信息进行区分得到第二测试包信息和第二生产包信息。
323.由于自定义包是根据服务名称进行配置的，因此可以获取到该自定义包的服务名称信息，以在服务名称信息下对包信息进行管理。
324.基于服务名称信息，对第二测试包信息和第二生产包信息进行比较得到第三比较结果，并根据第三比较结果标注第二测试包信息和第二生产包信息。
325.进一步的，对该服务名称信息下的第二测试包信息和第二生产包信息进行比较得到第三比较结果。
326.分别对第二测试包信息和第二生产包信息进行排序，并对排序后的第二测试包信
息和第二生产包信息进行格式转换得到目标格式的第二测试包信息和第二生产包信息。
327.在对第二测试包信息和第二生产包信息进行排序时，可以是按照字典序，亦即a-z的顺序进行排序得到排序后的第二测试包信息和第二生产包信息。
328.进一步的，由于在数据库中存储的第二测试包信息和第二生产包信息是以表格形式进行展示的，因此，可以将表格形式的第二测试包信息和第二生产包信息转换成json格式的第二测试包信息和第二生产包信息。
329.对目标格式的第二测试包信息和第二生产包信息进行比较得到第三比较结果。
330.在得到目标格式的第二测试包信息和第二生产包信息之后们可以进行文本比对确定第二测试包信息和第二生产包信息中不相同的配置项作为第三比较结果。
331.在确定第二测试包信息和第二生产包信息中不相同的配置项之后，可以将第二测试包信息和第二生产包信息中不相同的配置项标注出来，以便于开发人员对测试环境和生产环境中的第二测试包信息和第二生产包信息进行维护。
332.对自定义包的管理还可以包括配置导出功能。
333.获取与自定义包对应的服务名称信息。
334.由于自定义包是根据服务名称进行配置的，因此可以获取到该自定义包的服务名称信息，以在服务名称信息下对包信息进行管理。
335.基于服务名称信息，对通用包信息和定义包信息进行合并得到目标包信息。
336.由于对自定义包的包信息进行导出时，可能会牵扯到通用包的包信息，因此可以获取到通用包的通用包信息和自定义包的定义包信息，以对该服务名称信息下的通用包信息和定义包信息进行合并得到目标包信息。
337.在对通用包信息和定义包信息进行合并时，可以遵循自定义包的定义包信息优先的原则。
338.具体的，可以将通用包信息和定义包信息进行比较。当通用包信息与定义包信息产生差异或者冲突时，利用定义包信息覆盖通用包信息得到目标包信息。
339.对目标包信息进行拼接处理得到定义文本文件。
340.由于在数据库中存储的包信息是字段格式的，因此，可以将字段格式的目标包信息拼接成“包名＝＝版本号”的定义文本文件。该定义文本文件可以是requirements文件。
341.当应用程序依赖时，可以使用http接口通过acttachment返回该requirements文件，亦即requirements.txt。
342.图15示出了应用场景下构建通用镜像文件和定义镜像文件的方法的流程示意图，如图15所示，在步骤s1510中，拉取requirements.txt。
343.该requirements.txt可以包括通用文本文件和定义文本文件，可以通过配置后台拉取到。
344.在生成通用文本文件或定义文本文件之后，可以触发容器基础镜像的自动构建流程，以确保可以及时更新基础镜像，满足服务进程应用最新的python包引用。
345.在步骤s1520中，构建通用第三方包配置镜像层。
346.接收通用文本文件的安装指令，并根据通用文本文件构建通用包的通用镜像文件。
347.该通用文本文件的安装指令可以是pip install命令。
348.由于python项目中经常有一个requirements.txt文件，里面记录了当前程序的所有依赖包及其精确版本号。因此，通用的requirements.txt文件可以通过pip命令自动生成和安装。
349.其中，安装通用包的通用镜像文件的安装指令为pip install命令。
350.通过pip install命令安装通用配置的通用包的通用文本文件，以构建通用镜像文本，完成通用包配置的镜像层构建。
351.在步骤s1530中，构建服务自定义第三方镜像层。
352.接收定义文本文件的安装指令，并根据定义文本文件构建自定义包的定义镜像文件。
353.该定义文本文件的安装指令可以是pip install命令。
354.由于python项目中经常有一个requirements.txt文件，里面记录了当前程序的所有依赖包及其精确版本号。因此，自定义的requirements.txt文件也可以通过pip命令自动生成和安装。
355.其中，安装通用包的定义镜像文件的安装指令为pip install命令。
356.通过pip install命令安装自定义配置的自定义包的定义文本文件，以构建定义镜像文本，完成自定义包配置的镜像层构建。
357.其中，目前采用的方式是包信息集中管理的方式，配置后台统一管理通用包的包信息和自定义包的包信息。在镜像构建时按需获取配置文件，并应用到构建过程中。
358.除此之外，还可以对通用包的包信息和自定义包的包信息进行分散式管理。每个服务各自维护第三方python包的包信息。在需要查询或者进行修改时，可以从各项目中拉取对应的包信息，完成修改后再推送回项目，使得包信息作为项目文件的一部分进行管理。
359.这种方式能够在构建镜像层的过程中主动推送requirements.txt文件，使得镜像层的构建的自动化和智能化程度更高。
360.在本公开的示例性实施例中的程序文件的管理方法，对包信息和进程信息的上报可以使得开发人员对服务运行情况和代码依赖情况有更好的感知和掌控。利用sdk上报python包的信息，有助于开发人员了解进程运行时对python包的实际引用状态，帮助开发人员区分python包的配置项是否真正生效，提高了问题定位和追踪的效率。在现有的方案中们对于服务依赖的python包的版本判断，基本依靠查询物理上的依赖情况判断，而在容器化改造后容器环境的的登录操作流程较多，更不便于对python包的版本查询。通过服务上报信息，并在查询后台提供展示和检索的功能，能够大大减少查询的操作时间和步骤，并对信息的聚合有更加概括性的同一观感。
361.相较于直接部署在物理机上的服务共同使用python包而言，本公开能够对服务、进程依赖的python包进行精细化管理。第三方python包配置后台提供了不同粒度的配置方式，能够在较小的维护成本的前提下，以一种更加灵活的方式控制不同服务的包信息，也为特殊版本指定和版本灰度测试等场景提供了更加便捷的解决方案。更进一步的，新版本的python包先在小范围内应用，然后在大规模推广，对系统的可用性和稳定性的提升也提供了帮助。
362.包信息的管理后台对配置和ci/cd流程解耦起到了重要作用。ci/cd流程不需要依赖固定的配置文件，而配置的修改也可以便捷地触发容器镜像的ci/cd流程。采取通用的第
三方通用包和自定义包镜像层隔离的方式进行镜像构建，可以在python包配置修改时自动触发镜像层的构建，提高了镜像层的构建效率，也使得配置修改的流程与项目代码的修改完全解耦，减少了维护成本，也提升了包信息的构架和部署效率。
363.此外，在本公开的示例性实施例中，还提供了一种程序文件的管理装置。图16示出了程序文件的管理装置的结构示意图，如图16所示，程序文件的管理装置1600可以包括：信息解析模块1610、信息比较模块1620和文件管理模块1630。其中：
364.信息解析模块1610，被配置为获取程序包的包信息以及与程序包对应的进程信息，并对进程信息进行解析处理得到更新后的进程信息；信息比较模块1620，被配置为获取当前进程的当前信息，并对当前信息和更新后的进程信息进行比较得到第一比较结果；文件管理模块1630，被配置为根据第一比较结果对更新后的进程信息进行剔除处理得到目标信息，以通过包信息和目标信息对程序包进行管理。
365.在本发明的一种示例性实施例中，在对所述进程信息进行解析处理得到更新后的所述进程信息之后，所述方法还包括：
366.存储所述包信息和所述更新后的进程信息。
367.在本发明的一种示例性实施例中，所述通过所述包信息和所述目标信息对所述程序包进行管理，包括：
368.确定所述程序包的适用范围，并根据所述适用范围将所述程序包确定为通用包和自定义包；
369.通过所述包信息和所述目标信息对所述通用包或所述自定义包进行管理。
370.在本发明的一种示例性实施例中，所述通过所述包信息和所述目标信息对所述通用包或所述自定义包进行管理，包括：
371.获取所述通用包或所述自定义包的环境参数，并根据所述环境参数确定所述通用包或所述自定义包的当前环境；
372.在所述当前环境下，根据所述包信息和所述目标信息对所述通用包进行管理；
373.在所述当前环境下，根据所述包信息和所述目标信息对所述自定义包进行管理。
374.在本发明的一种示例性实施例中，所述包信息包括包名信息，所述根据所述包信息和所述目标信息对所述通用包进行管理，包括：
375.根据所述包名信息或者所述目标信息查询所述包信息，并显示所述包信息。
376.在本发明的一种示例性实施例中，在显示所述包信息之后，所述根据所述包信息和所述目标信息对所述通用包进行管理，包括：
377.基于所述目标信息，根据所述包信息对所述通用包进行配置修改得到通用配置记录，以根据所述通用配置记录更新所述通用包的所述包信息。
378.在本发明的一种示例性实施例中，所述根据所述包信息对所述通用包进行配置修改得到通用配置记录，包括：
379.新增与所述包信息对应的通用配置记录；
380.修改所述包信息得到通用配置记录；
381.删除所述包信息得到通用配置记录。
382.在本发明的一种示例性实施例中，所述当前环境包括测试环境和生产环境，
383.所述根据所述包信息和所述目标信息对所述通用包进行管理，包括：
384.根据所述测试环境和所述生产环境对所述包信息进行区分得到第一测试包信息和第一生产包信息；
385.对所述第一测试包信息和所述第一生产包信息进行比较得到第二比较结果，并根据所述第二比较结果标注所述第一测试包信息和所述第一生产包信息。
386.在本发明的一种示例性实施例中，所述对所述第一测试包信息和所述第一生产包信息进行比较得到第二比较结果，包括：
387.分别对所述第一测试包信息和所述第一生产包信息进行排序，并对排序后的所述第一测试包信息和所述第一生产包信息进行格式转换得到目标格式的所述第一测试包信息和所述第一生产包信息；
388.对所述目标格式的所述第一测试包信息和所述第一生产包信息进行比较得到第二比较结果。
389.在本发明的一种示例性实施例中，所述根据所述包信息和所述目标信息对所述通用包进行管理，包括：
390.基于所述目标信息，对所述包信息进行拼接处理得到通用文本文件。
391.在本发明的一种示例性实施例中，所述方法还包括：
392.接收所述通用文本文件的安装指令，并根据所述通用文本文件构建所述通用包的通用镜像文件。
393.在本发明的一种示例性实施例中，所述包信息包括包名信息，
394.所述根据所述包信息和所述目标信息对所述自定义包进行管理，包括：
395.获取与所述自定义包对应的服务名称信息；
396.基于所述服务名称信息，根据所述包名信息或者所述目标信息查询所述包信息，并显示所述包信息。
397.在本发明的一种示例性实施例中，所述根据所述包信息和所述目标信息对所述自定义包进行管理，包括：
398.基于所述目标信息，获取与所述自定义包对应的服务名称信息；
399.基于所述服务名称信息，基于所述服务名称信息，根据所述包信息对所述自定义包进行配置修改得到定义配置记录，以根据所述定义配置记录更新所述自定义包的所述包信息。
400.在本发明的一种示例性实施例中，所述根据所述包信息对所述自定义包进行配置修改得到定义配置记录，包括：
401.新增与所述包信息对应的定义配置记录；
402.修改所述包信息得到定义配置记录；
403.删除所述包信息得到定义配置记录。
404.在本发明的一种示例性实施例中，所述当前环境包括测试环境和生产环境，
405.所述根据所述包信息和所述目标信息对所述自定义包进行管理，包括：
406.根据所述测试环境和所述生产环境对所述包信息进行区分得到第二测试包信息和第二生产包信息，并获取与所述自定义包对应的服务名称信息；
407.基于所述服务名称信息，对所述第二测试包信息和所述第二生产包信息进行比较得到第三比较结果，并根据所述第三比较结果标注所述第二测试包信息和所述第二生产包
信息。
408.在本发明的一种示例性实施例中，所述对所述第二测试包信息和所述第二生产包信息进行比较得到第三比较结果，包括：
409.分别对所述第二测试包信息和所述第二生产包信息进行排序，并对排序后的所述第二测试包信息和所述第二生产包信息进行格式转换得到目标格式的所述第二测试包信息和所述第二生产包信息；
410.对所述目标格式的所述第二测试包信息和所述第二生产包信息进行比较得到第三比较结果。
411.在本发明的一种示例性实施例中，所述包信息分为通用包信息和定义包信息，
412.所述根据所述包信息和所述目标信息对所述自定义包进行管理，包括：
413.基于所述目标信息，获取与所述自定义包对应的服务名称信息；
414.基于所述服务名称信息，对所述通用包信息和所述定义包信息进行合并得到目标包信息；
415.对所述目标包信息进行拼接处理得到定义文本文件。
416.在本发明的一种示例性实施例中，所述方法还包括：
417.接收所述定义文本文件的安装指令，并根据所述定义文本文件构建所述自定义包的定义镜像文件。
418.在本发明的一种示例性实施例中，在通过所述包信息和所述目标信息对所述程序包进行管理之后，所述方法还包括：
419.移除所述包信息。
420.上述程序文件的管理装置1600的具体细节已经在对应的程序文件的管理方法中进行了详细的描述，因此此处不再赘述。
421.应当注意，尽管在上文详细描述中提及了程序文件的管理装置1600的若干模块或者单元，但是这种划分并非强制性的。实际上，根据本公开的实施方式，上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之，上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。
422.此外，在本公开的示例性实施例中，还提供了一种能够实现上述方法的电子设备。
423.下面参照图17来描述根据本发明的这种实施例的电子设备1700。图17显示的电子设备1700仅仅是一个示例，不应对本发明实施例的功能和使用范围带来任何限制。
424.如图17所示，电子设备1700以通用计算设备的形式表现。电子设备1700的组件可以包括但不限于：上述至少一个处理单元1710、上述至少一个存储单元1720、连接不同系统组件(包括存储单元1720和处理单元1710)的总线1730、显示单元1740。
425.其中，所述存储单元存储有程序代码，所述程序代码可以被所述处理单元1710执行，使得所述处理单元1710执行本说明书上述“示例性方法”部分中描述的根据本发明各种示例性实施例的步骤。
426.存储单元1720可以包括易失性存储单元形式的可读介质，例如随机存取存储单元(ram)1721和/或高速缓存存储单元1722，还可以进一步包括只读存储单元(rom)1723。
427.存储单元1720还可以包括具有一组(至少一个)程序模块1725的程序/实用工具1724，这样的程序模块1725包括但不限于：操作系统、一个或者多个应用程序、其它程序模
块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。
428.总线1730可以为表示几类总线结构中的一种或多种，包括存储单元总线或者存储单元控制器、外围总线、图形加速端口、处理单元或者使用多种总线结构中的任意总线结构的局域总线。
429.电子设备1700也可以与一个或多个外部设备1900(例如键盘、指向设备、蓝牙设备等)通信，还可与一个或者多个使得用户能与该电子设备1700交互的设备通信，和/或与使得该电子设备1700能与一个或多个其它计算设备进行通信的任何设备(例如路由器、调制解调器等等)通信。这种通信可以通过输入/输出(i/o)接口1750进行。并且，电子设备1700还可以通过网络适配器1760与一个或者多个网络(例如局域网(lan)，广域网(wan)和/或公共网络，例如因特网)通信。如图所示，网络适配器1760通过总线1730与电子设备1700的其它模块通信。应当明白，尽管图中未示出，可以结合电子设备1700使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、raid系统、磁带驱动器以及数据备份存储系统等。
430.通过以上的实施例的描述，本领域的技术人员易于理解，这里描述的示例实施例可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本公开实施例的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是cd-rom，u盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、终端装置、或者网络设备等)执行根据本公开实施例的方法。
431.在本公开的示例性实施例中，还提供了一种计算机可读存储介质，其上存储有能够实现本说明书上述方法的程序产品。在一些可能的实施例中，本发明的各个方面还可以实现为一种程序产品的形式，其包括程序代码，当所述程序产品在终端设备上运行时，所述程序代码用于使所述终端设备执行本说明书上述“示例性方法”部分中描述的根据本发明各种示例性实施例的步骤。
432.参考图18所示，描述了根据本发明的实施例的用于实现上述方法的程序产品1800，其可以采用便携式紧凑盘只读存储器(cd-rom)并包括程序代码，并可以在终端设备，例如个人电脑上运行。然而，本发明的程序产品不限于此，在本文件中，可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。
433.所述程序产品可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以为但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(ram)、只读存储器(rom)、可擦式可编程只读存储器(eprom或闪存)、光纤、便携式紧凑盘只读存储器(cd-rom)、光存储器件、磁存储器件、或者上述的任意合适的组合。
434.计算机可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了可读程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。可读信号介质还可以是可读存储介质以外的任何可读介质，该可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。
435.可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于无线、有线、光缆、rf等等，或者上述的任意合适的组合。
436.可以以一种或多种程序设计语言的任意组合来编写用于执行本发明操作的程序代码，所述程序设计语言包括面向对象的程序设计语言—诸如java、c 等，还包括常规的过程式程序设计语言—诸如“c”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、作为一个独立的软件包执行、部分在用户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中，远程计算设备可以通过任意种类的网络，包括局域网(lan)或广域网(wan)，连接到用户计算设备，或者，可以连接到外部计算设备(例如利用因特网服务提供商来通过因特网连接)。
437.本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其他实施例。本技术旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由权利要求指出。