CN117435243A - 一种自动化合包及部署方法与系统 - Google Patents

Abstract

本发明提出一种自动化合包及部署方法与系统，该方法包括：在代码仓库中为目标应用创建目录；响应于用户的上传操作，获取用户上传的应用包；对应用包进行解析，获取目标可执行文件；将目标可执行文件与相应目标应用目录下的可执行文件进行一致性比对，确定需要更新的代码片段；基于需要更新的代码片段，合成新的可执行文件；将新的可执行文件上传至代码仓库相应的目标应用的目录下，并记录更新时间；响应于用户需求，从代码仓库中拉取与用户需求匹配的目标版本的可执行文件和所需的依赖库及资源文件，生成目标应用包；将目标应用包部署到至少一个目标平台。本发明可以减少应用包冲突，提高整体开发和部署流程的效率。

Description

一种自动化合包及部署方法与系统

技术领域

本发明涉及计算机技术领域，具体涉及一种自动化合包及部署方法与系统。

背景技术

随着软件系统的功能和复杂度的提高，软件的更新速度变得越来越频繁。每个规模化应用的软件系统都面临着大量开发新功能应用包和修复问题补丁包的任务大规模的开发团队协作已是开发中的常见模式。

目前行业内广泛使用的SVN和Git等版本控制系统可以部分解决合并源代码的问题，但是，对于各个开发小组打包编译后生成的部署应用包里面的可执行文件的冲突，仍然只能依靠人工根据打包时间筛选出最新的应用包，但无法判断应用包里面的可执行文件是否包含所有的内容。在同时存在多个版本迭代以及同时存在应用包和问题补丁包的情况下，很容易发生功能代码被覆盖以及丢失的情况。

另一方面，这些应用包被手工部署到多云平台上时，由于各个云平台厂商各自使用自己的一套接入标准，导致部署应用包步骤繁琐，耗时长，并且容易出错。

发明内容

发明目的：本发明旨在针对当前分组开发场景下的应用包合包问题和部署问题，提出一种自动化合包及部署方法与系统。

发明内容：为实现上述目的，本发明提出以下技术方案：

第一方面，本发明提出一种自动化合包及部署方法，所述方法包括步骤：

在代码仓库中为目标应用创建目录，以保存所述目标应用的可执行文件；

响应于用户的上传操作，获取用户上传的应用包；

对所述应用包进行解析，获取目标可执行文件；

将所述目标可执行文件与对应的所述目标应用目录下的可执行文件进行一致性比对，确定需要更新的代码片段；

基于所述需要更新的代码片段，合成新的可执行文件；

将所述新的可执行文件上传至所述代码仓库相应的目标应用的目录下，并记录更新时间；

响应于用户需求，从所述代码仓库中拉取与所述用户需求匹配的目标版本的可执行文件和所需的依赖库及资源文件，生成目标应用包；

将所述目标应用包部署到至少一个目标平台。

在第一方面所述方法的一种可选实施方式中，在获取用户上传的应用包之后，还包括：

获取所述应用包的名称，通过正则表达式对所述名称进行关键词匹配；

若所述应用包的名称不符合预设的命名规范，则拒绝所述应用包上传；

若所述应用包的名称符合所述命名规范，则基于匹配结果，确定所述应用包的分类；并基于所述应用包的分类，确定所述应用包对应的代码仓库。

在第一方面所述方法的一种可选实施方式中，在将所述新的可执行文件上传至所述代码仓库相应的目标应用的目录下之后，还包括：

获取所述代码仓库为所述新的可执行文件分发的哈希值，将所述哈希值与对应的可执行文件关联存储，以使所述代码仓库能够基于所述哈希值回滚至用户所需的可执行文件版本。

在第一方面所述方法的一种可选实施方式中，将所述目标可执行文件与对应的所述目标应用目录下的可执行文件进行一致性比对，确定需要更新的代码片段，具体包括：

确定所述目标可执行文件对应的目标应用的目录下是否有同名文件，若没有，则确定所述目标可执行文件为所述需要更新的代码片段；若有，则通过反编译器对所述目标可执行文件的可执行内容和所述同名文件的可执行内容进行静态分析，基于静态分析结果，确定所述需要更新的代码片段。

在第一方面所述方法的一种可选实施方式中，所述方法还包括：

响应于所述目标应用包生成，基于所述用户需求，选取预先构建的灰度环境、测试用例和测试数据；

将所述目标应用包部署到所述灰度环境中，并基于所述测试用例和所述测试数据，对所述目标应用包进行测试，获取测试结果。

在第一方面所述方法的一种可选实施方式中，将所述目标应用包部署到至少一个目标平台，具体包括：

通过预设的网关模块预先与所述至少一个目标平台的供应商完成鉴权流程；

将所述应用包推送到所述目标平台上，并调用所述目标平台的供应商提供的OpenAPI接口部署应用包。

具体来说，在部署所述目标应用包后，还可以包括以下步骤：

利用所述网关模块解析所述目标平台针对本次应用包部署的响应信息；

基于所述响应信息，确定所述目标应用包的部署进度；若部署失败，则生成告警信息。

在一种更具体的实施方式中，若所述目标应用包部署失败，还包括：

通过调用预先编辑的Bash脚本对所述目标应用包进行自动化回滚和恢复，将所述目标应用包恢复到之前的可用版本。

在一种更具体的实施方式中，所述方法还包括：

基于所述响应信息，确定所述目标应用包的部署进度达到一半时，对所述目标应用包进行功能验证；

基于所述响应信息，确定所述目标应用包的部署完毕时，基于下游任务进行资源配置。

第二方面，提供了一种自动化合包及部署系统，用于实现所述自动化合包及部署方法，包括：

合包系统，用于在代码仓库中为目标应用创建目录，以保存所述目标应用的可执行文件；响应于用户的上传操作，获取用户上传的应用包；对所述应用包进行解析，获取目标可执行文件；将所述目标可执行文件与对应的所述目标应用目录下的可执行文件进行一致性比对，确定需要更新的代码片段；基于所述需要更新的代码片段，合成新的可执行文件；将所述新的可执行文件上传至所述代码仓库相应的目标应用的目录下，并记录更新时间；响应于用户需求，从所述代码仓库中拉取与所述用户需求匹配的目标版本的可执行文件和所需的依赖库及资源文件，生成目标应用包；

部署系统，用于将所述目标应用包部署到至少一个目标平台。

有益效果：与现有技术相比，本发明具有以下优势：

本发明提供的自动化合包及部署方法，可以减少应用包冲突，大大提高整体开发和部署流程的效率。通过自动化系统和流程，可以快速地将应用程序的不同组件和依赖项合并为一个可部署的包，并自动部署到目标环境中，减少了繁琐的手动操作和时间成本。

附图说明

图1为实施例涉及的一种自动化合包及部署方法的流程示意图；

图2为实施例涉及的一种自动化合包及部署系统的结构示意图；

图3为实施例涉及的一种合包系统的结构示意图；

图4为实施例涉及的一种部署系统的结构示意图。

具体实施方式

下面将结合附图和具体实施例对本发明作更进一步的说明。但应当理解的是，本发明可以以各种形式实施，以下在附图中出示并且在下文中描述的一些示例性和非限制性实施例，并不意图将本发明限制于所说明的具体实施例。

应当理解的是，在技术上可行的情况下，以上针对不同实施例所列举的技术特征可以相互组合，从而形成本发明范围内的另外的实施例。此外，本发明所述的特定示例和实施例是非限制性的，并且可以对以上所阐述的结构、步骤、顺序做出相应修改而不脱离本发明的保护范围。

请参考图1，图1示例性地给出一种自动化合包及部署方法的流程示意图，该流程包括步骤S100至步骤S114：

S100：在代码仓库中为目标应用创建目录，以保存目标应用的可执行文件。

S102：响应于用户的上传操作，获取用户上传的应用包。

S104：对应用包进行解析，获取目标可执行文件。

S106：将目标可执行文件与相应目标应用目录下的可执行文件进行一致性比对，确定需要更新的代码片段。

S108：基于需要更新的代码片段，合成新的可执行文件。

S110：将新的可执行文件上传至代码仓库相应的目标应用的目录下，并记录更新时间。

S112：响应于用户需求，从代码仓库中拉取与用户需求匹配的目标版本的可执行文件和所需的依赖库及资源文件，生成目标应用包。

S114：将目标应用包部署到至少一个目标平台。

由上述技术方案内容可知，该方法可以自动化提取测试人员提交的应用包中的最新代码片段，基于最新代码片段做合包处理，可以减少应用包冲突。通过自动化处理流程，可以快速地将应用程序的不同组件和依赖项合并为一个可部署的包，并自动部署到目标环境中，减少了繁琐的手动操作和时间成本。

下面对图1所示的自动化合包及部署方法进行详细介绍。

首先对于步骤S100，在代码仓库中为目标应用创建目录，以保存目标应用的可执行文件。

对于一个大型的业务平台，其中会有很多系统，每个系统都有其独有的功能，比如考勤系统、财务系统、考试系统等。

在开发团队针对该业务平台开发时，提交的应用包可能是不同系统的应用包。为了确保合包的时候合并的是同一个应用的包，需要事先在每个系统的代码仓库中为该系统的每个应用创建对应的目录，用于保存编译后的可执行文件。这样，在生成目标应用包的时候只需要在这个应用目录下选择需要的可执行文件即可。

接着对于步骤S102，响应于用户的上传操作，获取用户上传的应用包。

在一些可实现的实施方式中，可以预先定义应用包的命名规则，例如，可以命名为：替换文件标识+前端包标识+系统名+平台标识+应用名+版本号+build号+发布日期。

基于这个命名规则构建正则表达式，该正则表达式可以对应用包的名称进行分析和关键字提取，进而可以判断这个应用包的名称是否符合上述命名规则。对于不符合命名规则的应用包，则禁止上传。而对于符合命名规则的应用包，则可以根据正则表达式匹配出的关键词确定应用包的分类，该分类用于表征该应用包属于哪个系统，基于应用包的分类，就可以确定该应用包对应的代码仓库。

接着对于步骤S104：对应用包进行解析，获取目标可执行文件。

开发人员提交的应用包通常为一个压缩文件，里面有很多包，而且是层层嵌套的。在对应用包进行解析时，需要一级级的进入每一个包，获取每一个包里面的目标可执行文件。

接着对于步骤S106：将目标可执行文件与相应目标应用目录下的可执行文件进行一致性比对，确定需要更新的代码片段。

在对获取的应用包进行解析后，会获得每一个目标可执行文件。但是这些目标可执行文件可能跟代码仓库中已有的可执行文件之间存在内容重复的情况。因此，需要对每一个目标可执行文件进行一致性对比，具体来说，就是判断代码仓库中对应目标应用的目录下有没有与这个目标可执行文件同名的可执行文件。如果没有，那么可以将这个目标可执行文件直接上传到代码仓库中对应目标应用的目录下。如果有同名文件，则使用反编译器采用静态分析法对比这两个文件的可执行内容。静态分析法可以分析出来这两个可执行文件的差异处，目标可执行文件相对于其同名文件的差异内容，就是需要更新的代码片段。

接着对于步骤S108：基于需要更新的代码片段，合成新的可执行文件。

在一些可实现的实施方式中，可以直接将需要更新的代码片段合成为新的可执行文件。也可以将需要更新的代码片段与代码仓库中其他的可执行文件进行合成，得到新的可执行文件。例如，可以将需要更新的代码片段与同名可执行文件合成为一个新的可执行文件，然后更新该新的可执行文件的更新时间。

接着对于步骤S110：将新的可执行文件上传至代码仓库相应的目标应用的目录下，并记录更新时间。

记录可执行文件的更新时间，可以方便查找文件和回滚文件。例如，当开发人员发现提交的可执行文件出错时，可以根据可执行文件的更新时间查找到相应的文件，也可以将代码回滚到更新时间之前的状态。

在一些可实现的实施方式中，还可以采用其他方式来实现可执行文件版本的回滚。例如，在将新的可执行文件上传至代码仓库相应的目标应用的目录下之后，还包括：获取代码仓库为新的可执行文件分发的哈希值，将哈希值与对应的可执行文件关联存储，以使代码仓库能够基于哈希值回滚至用户所需的可执行文件版本。

具体来说，在本步骤中，可以使用git来维护代码仓库的提交，每次提交代码后代码仓库会分配并返回一个哈希值，有回滚需求时只需要将git分配的哈希值再提交给git，git会将整个系统回滚至那个哈希值对应的版本。

接着对于步骤S112：响应于用户需求，从代码仓库中拉取与用户需求匹配的目标版本的可执行文件和所需的依赖库及资源文件，生成目标应用包。

用户需求描述了生成的目标应用的核心功能和使用场景等信息，可以通过构建需求匹配服务，从代码仓库中拉取符合用户需求的可执行文件和所需的依赖库及资源文件，最终构成一个完整的、可部署的目标应用包。

在一些可实现的实施方式中，在生成目标应用包之后，还可以将目标应用包部署到灰度环境进行自动化测试用例的验证。具体来说，可采用以下方式：

首先，需要根据用户需求选取预先构建的灰度环境，该灰度环境应当与生产环境相似，能够模拟生产环境的配置和条件。

其次，选取预先使用自动化测试框架和工具编写测试用例和测试数据，这些用例应该覆盖应用的核心功能和各种使用场景，确保测试的可重复性和准确性。

最后，将目标应用包自动部署到灰度环境中，确保在灰度环境中应用的安装、配置和依赖项与生产环境保持一致。如果检测出应用包的问题，可以及时发送消息给相关人员，以便相关人员能够及时重新合包上传。

通过在灰度环境中进行自动化测试，可以及早发现和解决潜在的问题，并降低将问题引入生产环境的风险。这种方法还可以为开发团队提供反馈和保障，在应用发布之前确保其质量和稳定性。

接着对于步骤S114：将目标应用包部署到至少一个目标平台。

在目标应用包部署阶段，若只需要部署到一个目标平台，则直接基于该目标平台的接入标准完成鉴权和部署即可。此处的目标平台，可以是云平台。

若需要将同一个目标应用包部署到多个目标平台，由于不同的目标平台的接入标准很可能不同，导致部署应用包步骤繁琐，耗时长，并且容易出错。为了解决这个问题，本实施例构建了一个网关模块，用于与各目标平台的供应商进行对接，对内实现屏蔽差异化，对外实现统一输出。具体来说，该网关模块具有以下功能：

根据选定的目标环境和配置，网关模块预先将访问各目标平台API所需的身份认证、密钥和令牌等凭证分别与各目标平台的供应商进行签名和鉴权。当需要部署目标应用包时，将合包生成的部署应用包推送到相应的云平台上，再调用各个供应商提供的OpenAPI接口部署应用包。部署完毕后，网关模块会接收到OpenAPI接口的响应信息，网关模块根据需要对响应信息进行解析，例如，对响应信息数据进行格式转换、协议转换以及数据结构转换，最终将响应信息转换成本地部署系统能够理解的数据格式，确保部署系统能够正确地解析和处理数据。当部署失败时会触发告警，部署系统可以发送告警信息通知运维人员进行紧急处理。同时，部署系统还可以通过调用预先编辑的Bash脚本进行自动化回滚和恢复，将应用程序恢复到之前的可用状态。

在一些可实现的实施方式中，可以采用一半一半这种渐进式部署策略部署目标应用包。具体来说，可以根据响应信息，确定目标应用包的部署进度达到一半时，对目标应用包进行功能验证；在确定目标应用包的部署完毕时，基于下游任务进行资源配置。

为实现上述自动化合包及部署方法，本实施例还提供了一种自动化合包及部署系统，该系统的结构如图2所示，包括合包系统和部署系统。

其中，合包系统用于在代码仓库中为目标应用创建目录，以保存目标应用的可执行文件；响应于用户的上传操作，获取用户上传的应用包；对应用包进行解析，获取目标可执行文件；将目标可执行文件与对应的目标应用目录下的可执行文件进行一致性比对，确定需要更新的代码片段；基于需要更新的代码片段，合成新的可执行文件；将新的可执行文件上传至代码仓库相应的目标应用的目录下，并记录更新时间；响应于用户需求，从代码仓库中拉取与用户需求匹配的目标版本的可执行文件和所需的依赖库及资源文件，生成目标应用包。部署系统用于将目标应用包部署到至少一个目标平台。

请参考图3，图3示意性地示出了合包系统的结构图，合包系统具体包括：

第一数据获取模块，用于获取用户上传的应用包。

解析模块，用于对应用包进行解析，获取目标可执行文件。

更新代码提取模块，用于将目标可执行文件与对应的目标应用目录下的可执行文件进行一致性比对，确定需要更新的代码片段。

合成模块，用于基于需要更新的代码片段，合成新的可执行文件，并将新的可执行文件上传至代码仓库相应的目标应用的目录下，代码仓库的时钟模块会为该目录下更新的可执行文件生成更新时间。

第二数据获取模块，用于获取用户需求。

生成模块，用于基于用户需求，从代码仓库中拉取与用户需求匹配的目标版本的可执行文件和所需的依赖库及资源文件，生成目标应用包。

请参考图4，图4示意性地示出了部署系统的结构图，部署系统具体包括：

网关模块，用于与目标平台的供应商完成鉴权流程；以及将目标应用包推送到目标平台上，并调用目标平台的供应商提供的OpenAPI接口部署目标应用包；还用于解析目标平台针对本次应用包部署的响应信息，基于响应信息，确定目标应用包的部署进度。

告警模块，用于在目标应用包部署失败时生成告警信息。

采用上述自动化合包及部署方法及系统，至少具有以下技术效果：

1、提高效率：自动化合包和部署可以大大提高整体开发和部署流程的效率。通过自动化系统和流程，可以快速地将应用程序的不同组件和依赖项合并为一个可部署的包，并自动部署到目标环境中，减少了繁琐的手动操作和时间成本。

2、一致性和准确性：自动化合包和部署可以确保部署过程的一致性和准确性。通过定义标准化的合包和部署流程，可以避免人为错误和配置差异，提高部署的质量和可靠性。

3、可重复性和可靠性：自动化合包和部署可以实现部署过程的可重复性和可靠性。通过自动执行的合包和部署流程，可以确保每次部署的步骤和配置都是一致的，减少了人为错误和配置问题带来的风险。

4、快速回滚和恢复：自动化合包和部署使快速回滚和恢复变得更加容易。如果出现问题或部署失败，可以快速回滚到之前的稳定版本，并恢复到可用状态，减少停机时间和业务影响。

5、可扩展性和灵活性：自动化合包和部署可以支持应用程序的快速扩展和资源管理。通过自动化的合包和部署流程，可以快速调整资源规模，以满足不同的负载需求和业务增长。

6、简化团队协作和管理：通过自动化合包和部署，团队成员可以更好地协同工作，并能够通过定义好的合包和部署流程进行管理。这有助于简化团队之间的合作，提高整体工作效率和协作效果。

7、通过自动化多平台部署，可以更好地管理和优化资源使用。可以根据需求动态调整云资源的规模和配置，以最大限度地降低成本，并提高资源利用率。

8、多平台环境灵活性：自动化多平台部署可以实现应用程序在不同平台上的灵活部署，使组织能够充分利用多个提供商的优势。它提供了更大的选择余地，能够根据需求选择最合适的平台，并在需要时进行切换或跨平台迁移。

以上所述实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

以上所述实施例仅表达了本发明的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若干变形和改进，这些都属于本发明的保护范围。因此，本发明专利的保护范围应以所附权利要求为准。

Claims (10)

1.一种自动化合包及部署方法，其特征在于，所述方法包括步骤：

在代码仓库中为目标应用创建目录，以保存所述目标应用的可执行文件；

响应于用户的上传操作，获取用户上传的应用包；

对所述应用包进行解析，获取目标可执行文件；

将所述目标可执行文件与相应目标应用目录下的可执行文件进行一致性比对，确定需要更新的代码片段；

基于所述需要更新的代码片段，合成新的可执行文件；

将所述新的可执行文件上传至所述代码仓库相应的目标应用的目录下，并记录更新时间；

响应于用户需求，从所述代码仓库中拉取与所述用户需求匹配的目标版本的可执行文件和所需的依赖库及资源文件，生成目标应用包；

将所述目标应用包部署到至少一个目标平台。

2.如权利要求1所述的方法，其特征在于，在获取用户上传的应用包之后，还包括：

获取所述应用包的名称，通过正则表达式对所述名称进行关键词匹配；

若所述应用包的名称不符合预设的命名规范，则拒绝所述应用包上传；

若所述应用包的名称符合所述命名规范，则基于匹配结果，确定所述应用包的分类；并基于所述应用包的分类，确定所述应用包对应的代码仓库。

3.如权利要求1所述的方法，其特征在于，在将所述新的可执行文件上传至所述代码仓库相应的目标应用的目录下之后，还包括：

获取所述代码仓库为所述新的可执行文件分发的哈希值，将所述哈希值与对应的可执行文件关联存储，以使所述代码仓库能够基于所述哈希值回滚至用户所需的可执行文件版本。

4.如权利要求1所述的方法，其特征在于，将所述目标可执行文件与对应的所述目标应用目录下的可执行文件进行一致性比对，确定需要更新的代码片段，具体包括：

确定所述目标可执行文件对应的目标应用的目录下是否有同名文件，若没有，则确定所述目标可执行文件为所述需要更新的代码片段；若有，则通过反编译器对所述目标可执行文件的可执行内容和所述同名文件的可执行内容进行静态分析，基于静态分析结果，确定所述需要更新的代码片段。

5.如权利要求1所述的方法，其特征在于，还包括：

响应于所述目标应用包生成，基于所述用户需求，选取预先构建的灰度环境、测试用例和测试数据；

将所述目标应用包部署到所述灰度环境中，并基于所述测试用例和所述测试数据，对所述目标应用包进行测试，获取测试结果。

6.如权利要求1所述的方法，其特征在于，将所述目标应用包部署到至少一个目标平台，具体包括：

通过预设的网关模块预先与所述至少一个目标平台的供应商完成鉴权流程；

将所述应用包推送到所述目标平台上，并调用所述目标平台的供应商提供的OpenAPI接口部署应用包。

7.如权利要求6所述的方法，其特征在于，在部署所述目标应用包后，还包括：

利用所述网关模块解析所述目标平台针对本次应用包部署的响应信息；

基于所述响应信息，确定所述目标应用包的部署进度；若部署失败，则生成告警信息。

8.如权利要求7所述的方法，其特征在于，若所述目标应用包部署失败，还包括：

通过调用预先编辑的Bash脚本对所述目标应用包进行自动化回滚和恢复，将所述目标应用包恢复到之前的可用版本。

9.如权利要求7所述的方法，其特征在于，还包括：

基于所述响应信息，确定所述目标应用包的部署进度达到一半时，对所述目标应用包进行功能验证；

基于所述响应信息，确定所述目标应用包的部署完毕时，基于下游任务进行资源配置。

10.一种自动化合包及部署系统，用于实现权利要求1至9任意一项所述的方法，其特征在于，包括：

合包系统，用于在代码仓库中为目标应用创建目录，以保存所述目标应用的可执行文件；响应于用户的上传操作，获取用户上传的应用包；对所述应用包进行解析，获取目标可执行文件；将所述目标可执行文件与对应的所述目标应用目录下的可执行文件进行一致性比对，确定需要更新的代码片段；基于所述需要更新的代码片段，合成新的可执行文件；将所述新的可执行文件上传至所述代码仓库相应的目标应用的目录下，并记录更新时间；响应于用户需求，从所述代码仓库中拉取与所述用户需求匹配的目标版本的可执行文件和所需的依赖库及资源文件，生成目标应用包；

部署系统，用于将所述目标应用包部署到至少一个目标平台。