Windows平台的客户端自动化打包和exe分发方法及装置

摘要

本发明提出了一种windows平台的客户端自动化打包和exe分发方法及装置，所述方法包括：部署Windows平台的各项环境配置，将所述windows平台作为持续集成工具进行调度的节点服务器；控制所述持续集成工具调用所述节点服务器，根据用户需求执行与所述持续集成工具对应的工具化操作；控制所述持续集成工具自行配置项目所需要的第三方应用的通知机制。所述装置使用了所述方法。本发明使得window平台客户端的打包和exe的分发的大部分操作可以自动化完成，有利于降低操作时间以及人力成本，同时提高了研发人员、测试人员和试用人员之间的信息交互效率，减轻研发人员排查问题的难度，减少排查时间，保障了测试效能。

权利要求

1.一种windows平台的客户端自动化打包和exe分发方法，其特征在于，包括：部署Windows平台的各项环境配置，使得 Windows平台能够适应exe安装包的打包环境和对应所需的各项环境，将所述windows平台作为持续集成工具进行调度的节点服务器；

控制所述持续集成工具调用所述节点服务器，根据用户需求执行与所述持续集成工具对应的工具化操作；

控制所述持续集成工具自行配置项目所需要的第三方应用的通知机制；

所述windows平台包括基于windows操作系统的多个台式电脑和手持移动装置，所述手持移动装置包括笔记本电脑、平板电脑和手机；所述控制所述持续集成工具调用所述节点服务器，根据用户需求执行与所述持续集成工具对应的工具化操作的步骤，具体为：控制所述持续集成工具同时调用多个所述节点服务器，根据用户需求同步执行与所述持续集成工具对应的持续集成构建、打包、上传或备份操作；

所述控制所述持续集成工具同时调用多个所述节点服务器，根据用户需求同步执行与所述持续集成工具对应的持续集成构建、打包、上传或备份操作的步骤，包括：控制所述持续集成工具调用多个Windows平台的客户端打包环境；

设置代码文件存储路径，并设置编译路径变量；

通过版本号变更区分客户端打包编译的前置条件，是否需要在路径变量下新建编译文件夹；

确定代码文件存储路径和所述前置条件后，更新工程文件；

在代码文件存储处，判断有无日志文件，若没有日志文件，则设置日志文件名称并保存编译时间；

根据脚本开始时间的格式作为日志文件的记录格式，对日志文件进行记录；

在客户端具体编译过程中，可选择的替换客户端的资源，并且记录每次打包的 SVN 版本信息，执行预设的编译操作后，生成默认命名的可执行文件；

确认可执行文件完成后，将上次自动打包生成的可执行文件删除，将默认命名的可执行文件按规则命名；

进行本地重要文件备份；

根据选择参数判断是否需要上传客户端pdb；

所述持续集成工具包括Jenkins，所述工程文件包括Visual Studio工程文件，所述第三方应用包括钉钉；将Jenkins作为主服务器，将各已部署的windows平台作为Node节点服务器，由Jenkins发出操作指令，并由多个Node节点服务器完成对应的工具化操作，所述工具化操作包括手工打包和上传exe安装包。

2.如权利要求1所述的方法，其特征在于，所述控制所述持续集成工具调用所述节点服务器，根据用户需求自行选择与所述持续集成工具对应的持续集成构建、打包、上传或备份操作的步骤，还包括：对编译打包完成的可执行文件和pdb进行统一管理，上传到网络服务器的固定目录下，生成并分发下载链接；

如果打包编译失败，则停止编译，并将失败信息打印到控制台。

3.一种windows平台的客户端自动化打包和exe分发装置，包括：部署模块，用于部署Windows平台的各项环境配置，使得 Windows平台能够适应exe安装包的打包环境和对应所需的各项环境，将所述windows平台作为持续集成工具进行调度的节点服务器；

第一控制模块，用于控制所述持续集成工具调用所述节点服务器，根据用户需求执行与所述持续集成工具对应的工具化操作；

第二控制模块，用于控制所述持续集成工具自行配置项目所需要的第三方应用的通知机制；

所述windows平台包括基于windows操作系统的多个台式电脑和手持移动装置，所述手持移动装置包括笔记本电脑、平板电脑和手机；所述控制所述持续集成工具调用所述节点服务器，根据用户需求执行与所述持续集成工具对应的工具化操作的步骤，具体为：控制所述持续集成工具同时调用多个所述节点服务器，根据用户需求同步执行与所述持续集成工具对应的持续集成构建、打包、上传或备份操作；

所述第一控制模块，具体用于：

控制所述持续集成工具调用多个Windows平台的客户端打包环境；

设置代码文件存储路径，并设置编译路径变量；

通过版本号变更区分客户端打包编译的前置条件，是否需要在路径变量下新建编译文件夹；

确定代码文件存储路径和所述前置条件后，更新工程文件；

在代码文件存储处，判断有无日志文件，若没有日志文件，则设置日志文件名称并保存编译时间；

根据脚本开始时间的格式作为日志文件的记录格式，对日志文件进行记录；

在客户端具体编译过程中，可选择的替换客户端的资源，并且记录每次打包的 SVN 版本信息，执行预设的编译操作后，生成默认命名的可执行文件；

确认可执行文件完成后，将上次自动打包生成的可执行文件删除，将默认命名的可执行文件按规则命名；

进行本地重要文件备份；

根据选择参数判断是否需要上传客户端pdb；

对编译打包完成的可执行文件和pdb进行统一管理，上传到网络服务器的固定目录下，生成并分发下载链接；

如果打包编译失败，则停止编译，并将失败信息打印到控制台；

所述持续集成工具包括Jenkins，所述工程文件包括Visual Studio工程文件，所述第三方应用包括钉钉。

4.一种计算机设备，包括存储器、处理器以及存储在所述存储器上并可在所述处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现如权利要求1至

2任意一项所述的windows平台的客户端自动化打包和exe分发方法。

5.一种计算机存储介质，其上存储有计算机程序，其特征在于，该程序被处理器执行时实现如权利要求1至2任意一项所述的windows平台的客户端自动化打包和exe分发方法。

说明书

Windows平台的客户端自动化打包和exe分发方法及装置

技术领域

[0001] 本发明涉及网络技术领域，具体涉及一种windows平台的客户端自动化打包和exe分发方法及装置。

背景技术

[0002] EXE文件（executable file，可执行文件）是一种可在操作系统存储空间中浮动定位的可执行程序。在 Windows 系统中的执行文件一般都采用exe 文件。在 windows 客户端测试的过程中，经常会有四种使用场景需要提供exe，分别是：场景一：通过人工修改代码，研发自测通过后，重新打包客户端，提供 exe 给客户进行联调；场景二：研发人员提测后，通过人工修改代码，重新打包客户端，将生成的 exe 安装包提供给测试人员进行验收；场景三：研发人员提测后，通过人工修改代码，重新打包客户端，将生成的 exe 安装包提供给公司其他人员进行试用。场景四：使用者在使用客户端安装包的过程中，出现一些bug，反馈到开发和测试人员这边进行复现、修复和验收确认。

[0003] 然而，以上四种场景，都会存在占用研发人员、测试人员和试用人员的时间，主要问题体现在四个方面：

[0004] 一、每次需要重新打包客户端，或者需要提供 exe 安装包时，都需要研发人员花费时间来修改代码、重新打包客户端和导出对应的 exe 安装包，特别是在测试过程中，研发人员要频繁进行打包和导出安装包的操作，需要重复消耗人力和时间资源；如果在打包的过程中出现操作问题、配置问题或者环境问题，提供安装包的时间也不可控；

[0005] 二、研发人员导出 exe 安装包后，需要通过通讯工具发送，测试人员和试用人员需要下载 exe 安装包，再安装使用；如果在下载的过程中，办公网络不稳定，容易下载失败或延长下载时间，测试和试用成本过高；

[0006] 三、测试人员在测试和验收过程中，要提前与研发人员确认本次的问题修复和提测功能，占用研发人员和测试人员的时间；

[0007] 四、由于现有的客户端打包机制缺乏打包信息、版本信息和该客户端版本编译时所生成的 pdb 文件（程序数据库文件），导致使用者反馈的bug不能定位到具体客户端问题，间接加大研发人员排查问题的难度，增加排查时间。

发明内容

[0008] 针对现有技术的不足，本发明提出一种windows平台的客户端自动化打包和exe分发方法及装置，解决了现有技术中客户端打包和exe分发时，需要人力频繁介入而导致的效率低下、测试和试用成本高等缺陷。

[0009] 本发明的技术方案是这样实现的：一种windows平台的客户端自动化打包和exe分发方法，包括：

[0010] 部署Windows平台的各项环境配置，将所述windows平台作为持续集成工具进行调度的节点服务器；

[0011] 控制所述持续集成工具调用所述节点服务器，根据用户需求执行与所述持续集成工具对应的工具化操作；

[0012] 控制所述持续集成工具自行配置项目所需要的第三方应用的通知机制。

[0013] 在其中一个实施例中，上述所述windows平台包括基于windows操作系统的多个台式电脑和手持移动装置，所述手持移动装置包括笔记本电脑、平板电脑和手机；所述控制所述持续集成工具调用所述节点服务器，根据用户需求执行与所述持续集成工具对应的工具化操作的步骤，具体为：

[0014] 控制所述持续集成工具同时调用多个所述节点服务器，根据用户需求同步执行与所述持续集成工具对应的持续集成构建、打包、上传或备份操作。

[0015] 在其中一个实施例中，上述所述控制所述持续集成工具同时调用多个所述节点服务器，根据用户需求同步执行与所述持续集成工具对应的持续集成构建、打包、上传或备份操作的步骤，包括：

[0016] 控制所述持续集成工具调用多个Windows平台的客户端打包环境；

[0017] 设置代码文件存储路径，并设置编译路径变量；

[0018] 通过版本号变更区分客户端打包编译的前置条件，是否需要在路径变量下新建编译文件夹；

[0019] 确定代码文件存储路径和所述前置条件后，更新工程文件；

[0020] 在代码文件存储处，判断有无日志文件，若没有日志文件，则设置日志文件名称并保存编译时间；

[0021] 根据脚本开始时间的格式作为日志文件的记录格式，对日志文件进行记录；

[0022] 在客户端具体编译过程中，可选择的替换客户端的资源，并且记录每次打包的 SVN 版本信息，执行预设的编译操作后，生成默认命名的可执行文件；

[0023] 确认可执行文件完成后，将上次自动打包生成的可执行文件删除，将默认命名的可执行文件按规则命名；

[0024] 进行本地重要文件备份；

[0025] 根据选择参数判断是否需要上传客户端 pdb。

[0026] 在其中一个实施例中，上述所述控制所述持续集成工具调用所述节点服务器，根据用户需求自行选择与所述持续集成工具对应的持续集成构建、打包、上传或备份操作的步骤，还包括：

[0027] 对编译打包完成的可执行文件和 pdb 进行统一管理，上传到网络服务器的固定目录下，生成并分发下载链接；

[0028] 如果打包编译失败，则停止编译，并将失败信息打印到控制台。

[0029] 在其中一个实施例中，所述持续集成工具包括Jenkins，所述工程文件包括Visual Studio工程文件，所述第三方应用包括钉钉。

[0030] 本发明还提供了一种windows平台的客户端自动化打包和exe分发装置，包括：

[0031] 部署模块，用于部署Windows平台的各项环境配置，将所述windows平台作为持续集成工具进行调度的节点服务器；

[0032] 第一控制模块，用于控制所述持续集成工具调用所述节点服务器，根据用户需求执行与所述持续集成工具对应的工具化操作；

[0033] 第二控制模块，用于控制所述持续集成工具自行配置项目所需要的第三方应用的通知机制。

[0034] 在其中一个实施例中，上述所述windows平台包括基于windows操作系统的多个台式电脑和手持移动装置，所述手持移动装置包括笔记本电脑、平板电脑和手机；所述第一控制模块，具体用于：

[0035] 控制所述持续集成工具同时调用多个所述节点服务器，根据用户需求同步执行与所述持续集成工具对应的持续集成构建、打包、上传或备份操作。

[0036] 在其中一个实施例中，上述所述第一控制模块，具体用于：

[0037] 控制所述持续集成工具调用多个Windows平台的客户端打包环境；

[0038] 设置代码文件存储路径，并设置编译路径变量；

[0039] 通过版本号变更区分客户端打包编译的前置条件，是否需要在路径变量下新建编译文件夹；

[0040] 确定代码文件存储路径和所述前置条件后，更新工程文件；

[0041] 在代码文件存储处，判断有无日志文件，若没有日志文件，则设置日志文件名称并保存编译时间；

[0042] 根据脚本开始时间的格式作为日志文件的记录格式，对日志文件进行记录；

[0043] 在客户端具体编译过程中，可选择的替换客户端的资源，并且记录每次打包的 SVN 版本信息，执行预设的编译操作后，生成默认命名的可执行文件；

[0044] 确认可执行文件完成后，将上次自动打包生成的可执行文件删除，将默认命名的可执行文件按规则命名；

[0045] 进行本地重要文件备份；

[0046] 根据选择参数判断是否需要上传客户端 pdb；

[0047] 对编译打包完成的可执行文件和 pdb 进行统一管理，上传到网络服务器的固定目录下，生成并分发下载链接；

[0048] 如果打包编译失败，则停止编译，并将失败信息打印到控制台。

[0049] 本发明还提供了一种计算机设备，包括存储器、处理器以及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现上述所述的windows平台的客户端自动化打包和exe分发方法。

[0050] 本发明还提供了一种计算机存储介质，其上存储有计算机程序，该程序被处理器执行时实现上述所述的windows平台的客户端自动化打包和exe分发方法。

[0051] 本发明实施例通过对Windows平台的各项环境配置进行针对性的部署，使得 Windows平台可以适应exe安装包的打包环境和其他所需的各项环境，并控制持续集成工具调用配置完成的windows平台，以调用配置完成的windows平台作为节点服务器，根据用户需求执行与所述持续集成工具对应的工具化操作，使得客户端的打包和exe的分发的大部分操作可以自动化完成，有利于降低操作时间以及人力成本，提高EXE软件开发过程中的测试效能，提高交付质量。同时，本发明实施例通过控制所述持续集成工具自行配置项目所需要的第三方应用的通知机制，使得各个流程的相关信息均可以通过第三方应用进行通知提醒，提高了研发人员、测试人员和试用人员之间的信息交互效率，减轻研发人员排查问题的难度，减少排查时间，进一步保障了测试效能。

附图说明

[0052] 为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

[0053] 图1为本发明第一实施例的windows平台的客户端自动化打包和exe分发方法的流程图；

[0054] 图2为本发明第二实施例的windows平台的客户端自动化打包和exe分发方法的流程图；

[0055] 图3为本发明第二实施例的钉钉作为第三方应用，在通知机制建立后弹出通知提醒的示意图；

[0056] 图4为本发明第三实施例的windows平台的客户端自动化打包和exe分发装置的结构框图；

[0057] 图5为本发明的又一实施方式的计算机内部构造示意图。

具体实施方式

[0058] 下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例，众所周知的模块、单元及其相互之间的连接、链接、通信或操作没有示出或未作详细说明。并且，所描述的特征、架构或功能可在一个或一个以上实施方式中以任何方式组合。本领域技术人员应当理解，下述的各种实施方式只用于举例说明，而非用于限制本发明的保护范围。还可以容易理解，本文所述和附图所示的各实施方式中的模块或单元或处理方式可以按各种不同配置进行组合和设计。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

[0059] 以下结合附图和具体实施方式对本发明的各个方面进行详细阐述。

[0060] 首先，对本发明可能涉及的名词及缩写及进行解释：

[0061] Win：Windows 操作系统的简称，是由美国微软公司（Microsoft）研发的操作系统。

[0062] exe：exe file 可执行程序，一种可在操作系统存储空间中浮动定位的可执行程序。在 Windows 系统中的执行文件一般都是 .exe 文件。

[0063] bug：计算机领域漏洞或缺陷。

[0064] Jenkins：一种持续集成工具。

[0065] Node：Jenkins的节点服务器的统称。

[0066] 变量：计算机名词，是计算机语言中能储存计算结果或能表示值的抽象概念。

[0067] Visual Studio：Microsoft Visual Studio，简称VS，是最流行的Windows平台应用程序的集成开发环境。

[0068] SVN：subversion的缩写，是一个开发源代码的版本控制系统，通过采用分支管理系统的高效管理，简而言之就是用于多个人共同开发同一个项目，实现共享资源，实现最终集中式的管理。

[0069] pdb：程序数据库文件，pdb文件是在编译工程的时候产生的，它是和对应的模块（exe或dll）一起生成出来的。

[0070] 第一实施例：

[0071] 请参照图1所示，本发明实施例公开了一种windows平台的客户端自动化打包和exe分发方法，包括：

[0072] S11，部署Windows平台的各项环境配置，将所述windows平台作为持续集成工具进行调度的节点服务器。

[0073] 在本实施例中，通过对Windows平台的各项环境配置进行针对性的部署，使得 Windows平台可以适应exe安装包的打包环境和其他所需的各项环境，本实施例的windows平台包括基于windows操作系统的多个台式电脑和手持移动装置，所述手持移动装置包括笔记本电脑、平板电脑和手机等。

[0074] S12，控制所述持续集成工具调用所述节点服务器，根据用户需求执行与所述持续集成工具对应的工具化操作。

[0075] 作为一种具体方案而非限定，S12具体包括：

[0076] 控制所述持续集成工具同时调用多个所述节点服务器，根据用户需求同步执行与所述持续集成工具对应的持续集成构建、打包、上传或备份操作。

[0077] 作为一种优选方案而非限定，本实施例的持续集成工具为Jenkins。本实施例通过将Jenkins作为主服务器，将各已部署的windows平台作为Node节点服务器，由Jenkins发出操作指令，并由多个Node节点服务器完成诸如手工打包和上传exe安装包等对应的工具化操作，避免消耗大量的人力和时间成本，提高了并发和效能。

[0078] S13，控制所述持续集成工具自行配置项目所需要的第三方应用的通知机制。

[0079] 上述第三方应用通常包括聊天或管理app，示例性的，第三方应用可以是微信、QQ、Skype或钉钉。

[0080] 本发明实施例通过对Windows平台的各项环境配置进行针对性的部署，使得 Windows平台可以适应exe安装包的打包环境和其他所需的各项环境，并控制持续集成工具调用配置完成的windows平台，以调用配置完成的windows平台作为节点服务器，根据用户需求执行与所述持续集成工具对应的工具化操作，使得客户端的打包和exe的分发的大部分操作可以自动化完成，有利于降低操作时间以及人力成本，提高EXE软件开发过程中的测试效能，提高交付质量。同时，本发明实施例通过控制所述持续集成工具自行配置项目所需要的第三方应用的通知机制，使得各个流程的相关信息均可以通过第三方应用进行通知提醒，提高了研发人员、测试人员和试用人员之间的信息交互效率，减轻研发人员排查问题的难度，减少排查时间，进一步保障了测试效能。

[0081] 第二实施例：

[0082] 请参照图2和图3所示，本发明实施例公开了另一种windows平台的客户端自动化打包和exe分发方法，包括：

[0083] S201，部署Windows平台的各项环境配置，将所述windows平台作为持续集成工具进行调度的节点服务器。

[0084] S201与第一实施例的对应步骤相同，在此不再赘诉。

[0085] 作为一种改进方案而非限定，本实施例S21还包括创建账号配置表user_info。

[0086] S202，控制所述持续集成工具调用多个Windows平台的客户端打包环境。

[0087] 与上述第一实施例相同的是，本实施例的持续集成工具为Jenkins。本实施例通过将Jenkins作为主服务器，将各已部署的windows平台作为Node节点服务器，由Jenkins发出操作指令，并由多个Node节点服务器完成诸如手工打包和上传exe安装包等对应的工具化操作，避免消耗大量的人力和时间成本，提高了并发和效能。

[0088] 本步骤S202的具体数据如下：

[0089] %comspec% /k ""C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat"" amd64_x86

[0090] S203，设置代码文件存储路径，并设置编译路径变量。

[0091] 本步骤S203的具体数据如下：

[0092] echo "‑‑‑‑‑‑‑‑‑‑‑设置路径‑‑‑‑‑‑‑‑‑‑‑"

[0093] set CodeBaseDir=D:\Jenkins\workspace\package_for_PolyvLive_64

[0094] set DepBaseDir=D:\Jenkins\workspace\package_for_PolyvLive_64\

[0095] dependencies2015

[0096] S204，通过版本号变更区分客户端打包编译的前置条件，是否需要在路径变量下新建编译文件夹。

[0097] 本步骤S204的具体数据如下：

[0098] echo "‑‑‑‑‑‑cmake更新Visual Studio工程文件‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑"[0099] echo "‑‑‑‑‑新版本打包需打开下面两个语句‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑"[0100] rd /s /Q %CodeBaseDir%\build

[0101] mkdir %CodeBaseDir%\build

[0102] cd %CodeBaseDir%\build

[0103] S205，确定代码文件存储路径和所述前置条件后，更新工程文件。

[0104] 作为一种优选方案而非限定，所述工程文件包括Visual Studio工程文件。本步骤S205的具体数据如下：

[0105] cmake .. ‑G "Visual Studio 15 2017 Win64" ^

[0106] ‑

[0107] DDepsPath:PATH=D:/Jenkins/workspace/package_for_PolyvLive_64/dependencies2015/win64/include ^

[0108]  ‑DQTDIR:PATH=C:/Qt/Qt5.12.5/5.12.5/msvc2017_64

[0109] S206，在代码文件存储处，判断有无日志文件，若没有日志文件，则设置日志文件名称并保存编译时间。

[0110] 本步骤S206的具体数据如下：

[0111] cd %CodeBaseDir%\package

[0112] ::设置日志文件名称并保存编译时间.

[0113] if not exist %CodeBaseDir%\package\output\log mkdir %CodeBaseDir%\package\output\log

[0114] S207，根据脚本开始时间的格式作为日志文件的记录格式，对日志文件进行记录。

[0115] 本步骤S207的具体数据如下：

[0116] set LogFile="%CodeBaseDir%\package\output\log\%date: 0,4%‑%date:~

[0117] 5,2%‑%date: 8,2%.log"~ ~

[0118] echo 开始时间：%date% %time% >> %LogFile%

[0119] echo 开始时间：%date% %time%

[0120] S208，在客户端具体编译过程中，可选择的替换客户端的资源，并且记录每次打包的 SVN 版本信息，执行预设的编译操作后，生成默认命名的可执行文件。

[0121] 本步骤S208的具体数据如下：

[0122] cd %CodeBaseDir%\package\res

[0123] echo "‑‑‑‑‑‑‑‑‑‑‑替换exe的res资源，多svn版本记录：SCM_CHANGELOG‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑"

[0124] "C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\VC\Tools\MSVC\14.16.27023\bin\Hostx64\x64\nmake.exe" /i /f %CodeBaseDir%\package\res\MakeFile SVN_VERSION="%version%.%SVN_REVISION_1%" BIN64=1 EXE_BIT="64">> %LogFile% 2>&1

[0125] cd %CodeBaseDir%\build

[0126] echo "‑‑‑‑‑‑‑编译生成可执行文件‑‑‑‑‑‑‑‑‑‑‑"

[0127] "C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\Bin\MSBuild.exe" polyvlive‑studio.sln /t:rebuild /p:Configuration=Release

[0128] S209，确认可执行文件完成后，将上次自动打包生成的可执行文件删除，将默认命名的可执行文件按规则命名。

[0129] 本步骤S209的具体数据如下：

[0130] echo "‑‑‑‑‑‑‑修改可执行文件为polyvlive64.exe‑‑‑‑‑‑‑‑‑‑"[0131] cd rundir\Release\bin\64bit

[0132] if not exist obs64.exe goto ExeNoExist

[0133] del polyvlive64.exe

[0134] ren obs64.exe polyvlive64.exe

[0135] C:\Qt\Qt5.12.5\5.12.5\msvc2017_64\bin\windeployqt.exe polyvlive64.exe[0136] cd C:\Workspace\polyv‑winlive

[0137] echo "‑‑‑‑‑‑‑切换到执行目录‑‑‑‑‑‑‑‑‑‑‑"

[0138] cd %CodeBaseDir%\package

[0139] echo "‑‑‑‑‑‑‑‑‑‑‑正在打包安装包‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑"[0140] "C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\VC\Tools\MSVC\14.16.27023\bin\Hostx64\x64\nmake.exe" /i /f %CodeBaseDir%\package\MakeFile SVN_VERSION="%version%.%SVN_REVISION_1%" BIN64=1 EXE_BIT="
64">> %LogFile% 2>&1

[0141] echo finishtime：%date% %time% >> %LogFile%

[0142] S210，进行本地重要文件备份。

[0143] 本步骤S210的具体数据如下：

[0144] echo "‑‑‑‑‑‑‑‑统一管理安装包‑‑‑‑‑‑‑‑‑‑‑‑‑‑"[0145] set packageDir=D:\xxz\V4PPT\PolyvLive

[0146] set _my_datetime=%date: 0,10%_%time: 0,5%~ ~

[0147] set _my_datetime=%_my_datetime: =_%

[0148] set _my_datetime=%_my_datetime::=_%

[0149] set _my_datetime=%_my_datetime:/=_%

[0150] set _my_datetime=%_my_datetime:.=_%

[0151] copy %CodeBaseDir%\package\output\PolyvLiveSetup.exe %packageDir%\PolyvLiveSetup_64_%version%.%SVN_REVISION_1%_%_my_datetime%.exe

[0152] copy %CodeBaseDir%\package\output\*.zip %packageDir%\pdb

[0153] S211，根据选择参数判断是否需要上传客户端 pdb。

[0154] 本步骤S211的具体数据如下：

[0155] if "%uploadPDB%"=="true" copy %CodeBaseDir%\package\output\*.zip D:\xxz\V4PPT\uploadPDB

[0156] echo "‑‑‑‑‑‑‑‑‑‑‑‑安装包名称‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑"[0157] echo PolyvLiveSetup_64_%version%.%SVN_REVISION

[0158] _1%_%_my_datetime%.exe

[0159] S212，对编译打包完成的可执行文件和 pdb 进行统一管理，上传到网络服务器的固定目录下，生成并分发下载链接。

[0160] 本实施例的下载链接可以是文本链接，或者是超链接，还可以是包含下载链接的二维码图片等。

[0161] 本步骤S212的具体数据如下：

[0162] cd ../

[0163] echo "‑‑‑‑‑‑‑‑统一管理安装包‑‑‑‑‑‑‑‑‑‑‑‑‑‑"[0164] echo "‑‑‑‑‑‑‑‑安装包分发 ‑‑‑‑‑‑‑‑‑‑‑‑‑‑"

[0165] cd D:\cwrsync

[0166] "D:\cwrsync\bin\rsync.exe" ‑avP ‑‑delete ‑‑chmod=755 /cygdrive/d/xxz/V4PPT/PolyvLive root@192.168.*.*::demo/testpackages/V4PPT

[0167] S213，如果打包编译失败，则停止编译，并将失败信息打印到控制台。

[0168] 本步骤S213的具体数据如下：

[0169] goto Finish

[0170] :ExeNoExist

[0171] echo "‑‑‑‑‑‑‑‑编译失败‑‑‑‑‑‑‑‑‑‑‑‑‑‑"

[0172] :Finish

[0173] echo "‑‑‑‑‑‑‑‑end‑‑‑‑‑‑‑‑‑‑‑‑‑‑"

[0174] S214，控制所述持续集成工具自行配置项目所需要的第三方应用的通知机制。

[0175] S214与第一实施例的对应步骤相同，在此不再赘诉。

[0176] 本发明实施例通过持续集成工具进行定时、手动和代码更新自动打包，克服了每次有代码修改，需要研发人员修改代码、重新打包客户端、导出并发送 exe 安装包的缺陷。通过持续集成打包后自动上传到服务器进行分发，通过扫描二维码或者点击下载链接后进行下载安装；解决了测试人员和试用人员下载 exe 安装包安装使用的操作问题。另外，本实施例通过持续集成工具每次打包构建时自动获取代码修改记录，可直接通过变更记录来了解；解决测试人员在测试和验收过程中需要反复确认代码的问题修复和提测功能点。最后，本实施例通过增加客户端的打包信息、版本信息和客户端版本编译时所生成的pdb文件，可以帮助研发人员快速定位问题，减轻研发人员排查问题的难度，减少排查时间，提高客户端的测试效能和交付质量。

[0177] 第三实施例：

[0178] 请参照图4所示，本发明还提供了一种windows平台的客户端自动化打包和exe分发装置100，包括部署模块110、第一控制模块120和第二控制模块130，其中：

[0179] 部署模块110，与第一控制模块120连接，用于部署Windows平台的各项环境配置，将所述windows平台作为持续集成工具进行调度的节点服务器；

[0180] 第一控制模块120，与第二控制模块130连接，用于控制所述持续集成工具调用所述节点服务器，根据用户需求执行与所述持续集成工具对应的工具化操作；

[0181] 第二控制模块130，用于控制所述持续集成工具自行配置项目所需要的第三方应用的通知机制。

[0182] 在本发明的实施方式中，所述windows平台包括基于windows操作系统的多个台式电脑和手持移动装置，所述手持移动装置包括笔记本电脑、平板电脑和手机；所述第一控制模块120，具体用于：

[0183] 控制所述持续集成工具同时调用多个所述节点服务器，根据用户需求同步执行与所述持续集成工具对应的持续集成构建、打包、上传或备份操作。

[0184] 在本发明的实施方式中，所述第一控制模块120，具体用于：

[0185] 控制所述持续集成工具调用多个Windows平台的客户端打包环境；

[0186] 设置代码文件存储路径，并设置编译路径变量；

[0187] 通过版本号变更区分客户端打包编译的前置条件，是否需要在路径变量下新建编译文件夹；

[0188] 确定代码文件存储路径和所述前置条件后，更新工程文件；

[0189] 在代码文件存储处，判断有无日志文件，若没有日志文件，则设置日志文件名称并保存编译时间；

[0190] 根据脚本开始时间的格式作为日志文件的记录格式，对日志文件进行记录；

[0191] 在客户端具体编译过程中，可选择的替换客户端的资源，并且记录每次打包的 SVN 版本信息，执行预设的编译操作后，生成默认命名的可执行文件；

[0192] 确认可执行文件完成后，将上次自动打包生成的可执行文件删除，将默认命名的可执行文件按规则命名；

[0193] 进行本地重要文件备份；

[0194] 根据选择参数判断是否需要上传客户端 pdb；

[0195] 对编译打包完成的可执行文件和 pdb 进行统一管理，上传到网络服务器的固定目录下，生成并分发下载链接；

[0196] 如果打包编译失败，则停止编译，并将失败信息打印到控制台。

[0197] 本实施例的模块与上述两个方法实施例中的步骤一一对应，在此不再赘诉。

[0198] 本发明实施例通过对Windows平台的各项环境配置进行针对性的部署，使得 Windows平台可以适应exe安装包的打包环境和其他所需的各项环境，并控制持续集成工具调用配置完成的windows平台，以调用配置完成的windows平台作为节点服务器，根据用户需求执行与所述持续集成工具对应的工具化操作，使得客户端的打包和exe的分发的大部分操作可以自动化完成，有利于降低操作时间以及人力成本，提高EXE软件开发过程中的测试效能，提高交付质量。同时，本发明实施例通过控制所述持续集成工具自行配置项目所需要的第三方应用的通知机制，使得各个流程的相关信息均可以通过第三方应用进行通知提醒，提高了研发人员、测试人员和试用人员之间的信息交互效率，减轻研发人员排查问题的难度，减少排查时间，进一步保障了测试效能。

[0199] 所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

[0200] 本发明实施例还提供了一种计算机存储介质，其上存储有计算机程序，该程序被处理器执行时实现如上述各实施例中的windows平台的客户端自动化打包和exe分发方法。

[0201] 本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各windows平台的客户端自动化打包和exe分发方法的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和/或易失性存储器。非易失性存储器可包括只读存储器（ROM）、可编程ROM（PROM）、电可编程ROM（EPROM）、电可擦除可编程ROM（EEPROM）或闪存。易失性存储器可包括随机存取存储器（RAM）或者外部高速缓冲存储器。作为说明而非局限，RAM以多种形式可得，诸如静态RAM（SRAM）、动态RAM（DRAM）、同步DRAM（SDRAM）、双数据率SDRAM（DDRSDRAM）、增强型SDRAM（ESDRAM）、同步链路（Synchlink） DRAM（SLDRAM）、存储器总线（Rambus）直接RAM（RDRAM）、直接存储器总线动态RAM（DRDRAM）、以及存储器总线动态RAM（RDRAM）等。

[0202] 或者，本发明上述集成的单元如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明实施例的技术方案本质上或者说对相关技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备（可以是个人计算机、终端、或者网络设备等）执行本发明各个实施例方法的全部或部分。而前述的存储介质包括：移动存储设备、RAM、ROM、磁碟或者光盘等各种可以存储程序代码的介质。

[0203] 与上述的计算机存储介质对应的是，在一个实施例中还提供一种计算机设备，该计算机设备包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其中，处理器执行程序时实现如上述各实施例中的windows平台的客户端自动化打包和exe分发方法。

[0204] 该计算机设备可以是终端，其内部结构图可以如图5所示。该计算机设备包括通过系统总线连接的处理器、存储器、网络接口、显示屏和输入装置。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统和计算机程序。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该计算机设备的网络接口用于与外部的终端通过网络连接通信。该计算机程序被处理器执行时以实现一种windows平台的客户端自动化打包和exe分发方法。该计算机设备的显示屏可以是液晶显示屏或者电子墨水显示屏，该计算机设备的输入装置可以是显示屏上覆盖的触摸层，也可以是计算机设备外壳上设置的按键、轨迹球或触控板，还可以是外接的键盘、触控板或鼠标等。

[0205] 本发明实施例通过对Windows平台的各项环境配置进行针对性的部署，使得 Windows平台可以适应exe安装包的打包环境和其他所需的各项环境，并控制持续集成工具调用配置完成的windows平台，以调用配置完成的windows平台作为节点服务器，根据用户需求执行与所述持续集成工具对应的工具化操作，使得客户端的打包和exe的分发的大部分操作可以自动化完成，有利于降低操作时间以及人力成本，提高EXE软件开发过程中的测试效能，提高交付质量。同时，本发明实施例通过控制所述持续集成工具自行配置项目所需要的第三方应用的通知机制，使得各个流程的相关信息均可以通过第三方应用进行通知提醒，提高了研发人员、测试人员和试用人员之间的信息交互效率，减轻研发人员排查问题的难度，减少排查时间，进一步保障了测试效能。

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

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