CN109491705B - 一种交付方法和装置 - Google Patents

Abstract

本申请提供了一种交付方法，包括：基于从开发基线接收到的版本发布申请，将完成程序的源码迁入组装基线；触发所述组装基线根据所述源码构建执行码，得到执行码组件文件；将所述执行码组件文件与预设输入相关文件进行版本合并，得到合并文件夹；依据预设的执行码依赖关系，对所述合并文件夹分配版本号信息，记录所述合并文件夹与所述版本号信息的对应关系；将所述合并文件夹迁入预设存储位置，并记录所述版本号信息与存储位置的对应关系。采用该方法，能够从开发基线获取源码并迁入组装基线以实现组装基线自动构件执行码，并进行分配版本号以及迁入存储位置，实现自动交付的过程。解决了现有技术中容易出现误操作以及版本交付速度低的问题。

Description

一种交付方法和装置

技术领域

本申请涉及电子设备领域，更具体的说，是涉及一种交付方法和装置。

背景技术

现有Windows系统生产线下，在开发过程中能够依赖TFS(Team FoundationServer，一种微软公司产品)进行相应自动化集成构建及部署过程中，对于开发完成版本交付过程中，版本审查等过程依赖人工，容易出现误操作以及版本交付速度低的问题

发明内容

有鉴于此，本申请提供了一种交付方法，解决了现有技术中容易出现误操作以及版本交付速度低的问题。

为实现上述目的，本申请提供如下技术方案：

一种交付方法，包括：

基于从开发基线接收到的版本发布申请，将完成程序的源码迁入组装基线；

触发所述组装基线根据所述源码构建执行码，得到执行码组件文件；

将所述执行码组件文件与包含版本信息的文档进行版本合并，得到合并文件夹；

依据预设的执行码依赖关系，对所述合并文件夹分配版本号信息，记录所述合并文件夹与所述版本号信息的对应关系；

将所述合并文件夹迁入预设存储位置，并记录所述版本号信息与存储位置的对应关系。

优选的，上述的方法，所述依据预设的执行码依赖关系，对所述合并文件夹分配版本号信息之后，所述将所述合并文件夹迁入预设存储位置之前，还包括：

依据预设的审查规则，对所述合并文件夹中的源码进行审查；

并基于审查结果为通过，执行所述将所述合并文件夹迁入预设存储位置步骤。

优选的，上述的方法，所述基于从开发基线接收到的版本发布申请，将完成程序的源码迁入组装基线之前，还包括：

接收所述版本发布申请以及包含版本信息的文档。

优选的，上述的方法，所述将所述合并文件夹迁入预设存储位置之后，还包括：

根据接收到的入库操作信息，将满足预设允许出库条件的合并文件夹迁入预设出库存储区域。

优选的，上述的方法，所述将满足预设允许出库条件的合并文件夹迁入预设出库存储区域之后，还包括：

根据输入的运行维护条件，分析得到与所述运行维护条件对应的第一版本号信息；

获取与所述第一版本号信息对应的合并文件夹；

依据所述合并文件夹中的版本信息更新对应的产品服务器。

优选的，上述的方法，所述接收输入的运行维护条件包括：

接收运行维护人员输入的操作信息，所述操作信息表征运行维护人员结合显示界面中的显示内容执行的修改操作和/或维护操作；

则所述依据所述合并文件夹中的版本信息更新对应的产品服务器，具体包括：

根据所述操作信息对所述产品服务器进行配置文件更新和/或维护；

或者

根据所述操作信息将所述合并文件夹中执行码组件对所述产品服务器的版本进行更新。

一种交付装置，包括：

基线模块，用于基于从开发基线接收到的版本发布申请，将完成程序的源码迁入组装基线；

构建模块，用于触发所述组装基线根据所述源码构建执行码，得到执行码组件文件；

合并模块，用于将所述执行码组件文件与预设输入相关文件进行版本合并，得到合并文件夹；

分配模块，用于依据预设的执行码依赖关系，对所述合并文件夹分配版本号信息，记录所述合并文件夹与所述版本号信息的对应关系；

存储模块，用于将所述合并文件夹迁入预设存储位置，并记录所述版本号信息与存储位置的对应关系。

优选的，上述的装置，还包括：

审查模块，用于依据预设的审查规则，对所述源码进行审查；

并基于审查结果为通过，触发所述存储模块。

优选的，上述的装置，还包括：

接收模块，用于接收所述版本发布申请以及包含版本信息的文档，以及接收入库操作信息；

所述存储模块，还用于在所述接收模块接收到入库操作信息时，将满足预设允许出库条件的合并文件夹迁入预设出库存储区域。

优选的，上述的装置，还包括：

显示模块，用于对应用所述交付装置的生产线中的相关信息进行显示；

操作模块，用于接收运行维护人员输入的操作信息，所述操作信息表征运行维护人员结合显示界面中的显示内容执行的修改操作和/或维护操作；

更新模块，根据所述操作信息对所述产品服务器进行配置文件更新和/或维护，或者根据所述操作信息将所述合并文件夹中执行码组件对所述产品服务器的版本进行更新。

经由上述的技术方案可知，与现有技术相比，本申请提供了一种交付方法，包括：基于从开发基线接收到的版本发布申请，将完成程序的源码迁入组装基线；触发所述组装基线根据所述源码构建执行码，得到执行码组件文件；将所述执行码组件文件与预设输入相关文件进行版本合并，得到合并文件夹；依据预设的执行码依赖关系，对所述合并文件夹分配版本号信息，记录所述合并文件夹与所述版本号信息的对应关系；将所述合并文件夹迁入预设存储位置，并记录所述版本号信息与存储位置的对应关系。采用该方法，能够从开发基线获取源码并迁入组装基线以实现组装基线自动构件执行码，并进行分配版本号以及迁入存储位置，将迁入预设存储未知的合并文件夹内执行码文件，实现工具自动化的更新至相关环境，实现自动交付的过程。解决了现有技术中容易出现误操作以及版本交付速度低的问题。

附图说明

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

图1为本申请提供的一种交付方法实施例1的流程图；

图2为本申请提供的一种交付方法实施例2的流程图；

图3为本申请提供的一种交付方法实施例3的流程图；

图4为本申请提供的一种交付方法实施例4的流程图；

图5为本申请提供的一种交付方法实施例5的流程图；

图6为本申请提供的一种交付装置实施例1的结构示意图；

图7为本申请提供的一种交付装置实施例2的结构示意图；

图8为本申请提供的一种交付装置实施例3的结构示意图；

图9为本申请提供的一种交付装置实施例4的结构示意图；

图10为本申请提供的一种交付方法的使用场景示意图；

图11为本申请提供的一种交付方法涉及的TFS与SADP-WIN的结构功能示意图；

图12为本申请提供的一种交付方法使用场景中显示界面的示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

本申请各实施例中涉及的一种交付方法以及装置是应用于Windows系统生产线，该生产线中能够生产基于Windows系统的软件产品，该软件产品具体是以代码形式表现。

需要说明的是，本方案涉及的Windows系统生产线中应用TFS，该交付方法以及装置应用于SADP-WIN(Windows系统端到端交付部署部署工具)与现有的TFS配合使用。

如图1所示的，为本申请提供的一种交付方法实施例1的流程图，该方法包括以下步骤：

步骤S101：基于从开发基线接收到的版本发布申请，将完成程序的源码迁入组装基线；

具体的，开发人员在开发基线中实现编辑程序，当其完成程序时，其录入程序完成清单并发布申请，以申请将其开发的程序进行交付。

具体实施中，开发基线中可以有很多个开发人员进行编辑程序，每个开发人员可以进行程序交付。

其中，当接收到该发布申请后，将源码从该开发基线中迁入组装基线，以使得该组装基线对于该源码进行处理。

步骤S102：触发所述组装基线根据所述源码构建执行码，得到执行码组件文件；

具体的，该组装基线接收到该源码时，对其进行自动构建执行码，得到执行码组件文件。

其中，该执行码组件文件中包含有执行码。

其中，该执行码是在软件运行过程中能够完成软件所要求的功能逻辑时，机器能够执行的代码。

具体实施中，该发布申请，需要将开发程序的源码提交至TFS服务器的源码管理服务器，同时触发TFS工具机制，以实现对源码的编译生成可运行执行码的过程。

步骤S103：将所述执行码组件文件与包含版本信息的文档进行版本合并，得到合并文件夹；

其中，将该构建得到的执行码组件文件与包含版本信息的文档进行版本合作，即在版本办理过程中，将以上文件合并在同一文件夹中，以实现将文档与执行码的合并工作成为版本合并。

步骤S104：依据预设的执行码依赖关系，对所述合并文件夹分配版本号信息，记录所述合并文件夹与所述版本号信息的对应关系；

其中，预设有执行码依赖关系，该依赖关系表征了当前更新的源码文件与历史源码文件之间的关系。

具体的，依据该执行码依赖关系，为该合并文件夹分配版本号信息，以使得根据该版本号信息对服务器的软件程序版本进行更新。

作为一个具体示例，项目组A.B.C三人同时在804批次进行项目开发工作，A人员更新了123及234两个源码文件，B更新了321及432两个文件，在版本分配过程中对于A人员的版本会分配版本号如Flag1，B人员版本号分配Flag2，在他们同时提交完版本信息后，C人员更新了321文件，C人员的更新时在B人员更新的基础上进行修改，在C人员进行版本办理的过程中配置管理员会分配版本号Flag2.1版本，由于在版本更新过程中需完成B人员的版本Flag2的更新后才能进行更新C人员的版本Flag2.1。

步骤S105：将所述合并文件夹迁入预设存储位置，并记录所述版本号信息与存储位置的对应关系。

其中，预设存储位置，该存储位置用于存储入库的相关信息。

具体的，将该合并文件夹迁入该预设存储位置，完成了交付过程。

并且，对该存储位置与该版本号信息的对应关系进行存储，以方便后续根据版本号信息从该存储位置获取相应的文件。

具体实施中，该预设存储位置可以包括版本办理的路径和环境更新的路径。

具体的，该存储位置是版本办理的路径时，后续可以基于该新的版本进行服务器的更新，该过程在后续实施例中会做详述，本实施例中不再解释。

具体的，该存储位置是环境更新的路径时，则可以直接根据该合并文件夹中的执行码对环境进行更新，无需进行合并文件夹中信息的迁移等过程。

综上，本实施例提供的一种交付方法，包括：基于从开发基线接收到的版本发布申请，将完成程序的源码迁入组装基线；触发所述组装基线根据所述源码构建执行码，得到执行码组件文件；将所述执行码组件文件与预设输入相关文件进行版本合并，得到合并文件夹；依据预设的执行码依赖关系，对所述合并文件夹分配版本号信息，记录所述合并文件夹与所述版本号信息的对应关系；将所述合并文件夹迁入预设存储位置，并记录所述版本号信息与存储位置的对应关系。采用该方法，能够从开发基线获取源码并迁入组装基线以实现组装基线自动构件执行码，并进行分配版本号以及迁入存储位置，实现自动交付的过程。解决了现有技术中由于依赖人工导致在版本交付过程中容易出现误操作以及版本交付速度低的问题。

如图2所示的，为本申请提供的一种交付方法实施例2的流程图，该方法包括以下步骤：

步骤S201：基于从开发基线接收到的版本发布申请，将完成程序的源码迁入组装基线；

步骤S202：触发所述组装基线根据所述源码构建执行码，得到执行码组件文件；

步骤S203：将所述执行码组件文件与包含版本信息的文档进行版本合并，得到合并文件夹；

步骤S204：依据预设的执行码依赖关系，对所述合并文件夹分配版本号信息，记录所述合并文件夹与所述版本号信息的对应关系；

其中，步骤S201-204与实施例1中的步骤S101-104一致，本实施例中不做赘述。

步骤S205：依据预设的审查规则，对所述合并文件夹中的源码进行审查；

具体的，预设审查规则，基于该审查规则对该源码进行审查，得到审查结果。

如果该基于源码通过该审查规则，即表示该源码满足审查规则，此时，执行步骤S206以为后续的部署流程提供正确的源码；如果该源码未通过该审查规则，即表示该源码不满足审查规则，此时，可以将该不通过的结果反馈给开发基线，以使得该开发基线中相应的开发人员对该源码进行修改或者其他处理等。

具体的，该审查规则是质量管理人员设置，其根据需要审核源码的各种要求，制定该审查规则。

具体实施中，该预设的审查规则可以是设置在产品审查库中，基于该产品审查库对于该源码进行产品审查。

具体实施中，还可以为质量管理人员直接对源码进行审查，并在得到审查结果后上传，如果审查结果为通过，执行步骤S206；否则，将该不通过的结果反馈给开发基线，以使得该开发基线中相应的开发人员对该源码进行修改或者其他处理等。

步骤S206：将所述合并文件夹迁入预设存储位置，并记录所述版本号信息与存储位置的对应关系。

其中，步骤S206与实施例1中的步骤S105一致，本实施例中不做赘述。

综上，本实施例提供的一种交付方法中，还包括：依据预设的审查规则，对所述合并文件夹中的源码进行审查；并基于审查结果为通过，执行所述触发所述组装基线根据所述源码构建执行码，得到执行码组件文件步骤。采用该方法能够在将合并文件夹迁入预设存储位子之前，对源码进行审查，提高准确程度。

如图3所示的，为本申请提供的一种交付方法实施例3的流程图，该方法包括以下步骤：

步骤S301：接收版本发布申请以及包含版本信息的文档；

其中，开发人员在开发基线完成程序编辑时，需要将其开发的程序交付。

具体的，开发人员在开发基线处申请版本发布，并上传包含版本信息的文档。

因此，与该开发基线相连的SADP-WIN中即可接收到该版本发布申请以及该包含版本信息的文档，以便后续步骤中根据该版本发布申请将源码从开发基线迁入组装基线，以及进行版本合并的过程。

步骤S302：基于从开发基线接收到的版本发布申请，将完成程序的源码迁入组装基线；

步骤S303：触发所述组装基线根据所述源码构建执行码，得到执行码组件文件；

步骤S304：将所述执行码组件文件与包含版本信息的文档进行版本合并，得到合并文件夹；

步骤S305：依据预设的执行码依赖关系，对所述合并文件夹分配版本号信息，记录所述合并文件夹与所述版本号信息的对应关系；

步骤S306：将所述合并文件夹迁入预设存储位置，并记录所述版本号信息与存储位置的对应关系。

其中，步骤S302-306与实施例1中的步骤S101-105一致，本实施例中不做赘述。

综上，本实施例提供的一种交付方法中，还包括：接收所述版本发布申请以及包含版本信息的文档。采用该方法，能够为后续步骤中根据该版本发布申请将源码从开发基线迁入组装基线，以及进行版本合并的过程提供依据。

如图4所示的，为本申请提供的一种交付方法实施例4的流程图，该方法包括以下步骤：

步骤S401：基于从开发基线接收到的版本发布申请，将完成程序的源码迁入组装基线；

步骤S402：触发所述组装基线根据所述源码构建执行码，得到执行码组件文件；

步骤S403：将所述执行码组件文件与包含版本信息的文档进行版本合并，得到合并文件夹；

步骤S404：依据预设的执行码依赖关系，对所述合并文件夹分配版本号信息，记录所述合并文件夹与所述版本号信息的对应关系；

步骤S405：将所述合并文件夹迁入预设存储位置，并记录所述版本号信息与存储位置的对应关系；

其中，步骤S401-405与实施例1中的步骤S101-105一致，本实施例中不做赘述。

步骤S406：根据接收到的入库操作信息，将满足预设允许出库条件的合并文件夹迁入预设出库存储区域。

其中，该合并文件夹中包含执行码文档。

具体实施中，该出库存储区域中设置有允许出库目录，可以将该满足允许出库条件的合并文件夹中包含的执行码文档放入该允许出库目录中。

具体的，版本管理人员确定该软件可以入库，则上传入库操作。

相应的，根据该入库操作信息，将该满足预设允许触控条件的合并文件夹迁入预设出库的存储区域，以做好出库的准备。

综上，本实施例提供的一种交付方法中，还包括：根据接收到的入库操作信息，将满足预设允许出库条件的合并文件夹迁入预设出库存储区域。采用该方法，通过版本管理人员指示的入库操作，将其中满足允许出库条件的合并文件夹迁入出库存储区域中，做好出库的准备。

如图5所示的，为本申请提供的一种交付方法实施例5的流程图，该方法包括以下步骤：

步骤S501：基于从开发基线接收到的版本发布申请，将完成程序的源码迁入组装基线；

步骤S502：触发所述组装基线根据所述源码构建执行码，得到执行码组件文件；

步骤S503：将所述执行码组件文件与包含版本信息的文档进行版本合并，得到合并文件夹；

步骤S504：依据预设的执行码依赖关系，对所述合并文件夹分配版本号信息，记录所述合并文件夹与所述版本号信息的对应关系；

步骤S505：将所述合并文件夹迁入预设存储位置，并记录所述版本号信息与存储位置的对应关系；

步骤S506：根据接收到的入库操作信息，将满足预设允许出库条件的合并文件夹迁入预设出库存储区域；

其中，步骤S501-506与实施例4中的步骤S401-406一致，本实施例中不做赘述。

步骤S507：根据输入的运行维护条件，分析得到与所述运行维护条件对应的第一版本号信息；

其中，运行维护人员根据需求，输入运行维护条件，以实现对产品服务器的软件进行更新。

具体的，该运行维护条件是与软件产品的环境相关。

具体的，根据该待更新的产品，确定其对应的版本号信息。

例如，产品A发布的版本信息为A1、A2、A3，产品B发布的版本信息为B1、B2、B3，运行维护人员在更新A产品的服务器时，输入A产品相应的条件，则可以确定对应的A1、A2、A3版本信息，更新B产品的时候，输入B产品相应的条件，则可以确定对应的B1、B2、B3版本信息。

步骤S508：获取与所述第一版本号信息对应的合并文件夹；

其中，在确定更新所需版本的第一版本号信息后，根据该第一版本号信息获取相应的合并文件夹。

具体的，从预设出库存储区域中获取该合并文件夹。

步骤S509：依据所述合并文件夹中的版本信息更新对应的产品服务器。

其中，根据该合并文件夹中的版本信息更新待更新的产品服务器中的软件。

作为一个具体示例，产品A的服务器包括两个类型A和B，在版本组包过程(步骤S502-504)中，在文件夹目录下A和B的相关文件分别存在A目录下及B目录下，版本目录下A、B两个子文件夹内执行码分别部署至A和B两个类型的服务器上。

具体的，该更新包括：更新服务器中的软件(执行码)、更新配置文件等各种内容。

作为一个具体示例，需更新配置文件，根据开发人员的开发任务而定，如开发任务需要修改一个开发的配置文件FLAG的属性值，如需修改会在发布的版本文档中体现。

作为一个具体示例，当对可视化界面进行修改时，也可以通过更新配置文件实现。

其中，该接收输入的运行维护条件包括：接收运行维护人员输入的操作信息，所述操作信息表征运行维护人员结合显示界面中的显示内容执行的修改操作和/或维护操作；

则步骤S509，具体包括：

根据所述操作信息对所述产品服务器进行配置文件更新和/或维护，或者根据所述操作信息将所述合并文件夹中执行码组件对所述产品服务器的版本进行更新。

需要说明的是，该执行码更新，就是环境内一个功能需要升级，升级的话涉及一个A文件的更新，在开发交付过程中，将A文件构建、合包、发布、迁入到存储文件夹后，运维人员去获取这个文件A，以使得根据获取的新的文件A自动去更新他们所使用的环境中原有的这个A文件。

其中，该SADP-WIN平台中设置有可视化的显示界面，可以对该Windows生产线交付过程中的数据进行监控，以及对产品服务器相关的各种相关信息进行显示。

具体的，该相关信息可以包括产品级配置文件的参数化配置信息、部署目标服务器地址配置信息、Windows生产线中产品各服务器类型中包含的各服务器地址及站点物理地址的配置信息。

需要说明的是，显示界面显示数据与提供的相关维护脚本关联。

具体的，该显示界面中可以对配置信息等进行显示，以使得运行维护人员能够基于显示内容对产品服务器进行更新和/或维护。

综上，本实施例提供的一种交付方法中，还包括：根据输入的运行维护条件，分析得到与所述运行维护条件对应的第一版本号信息；获取与所述第一版本号信息对应的合并文件夹；依据所述合并文件夹中的版本信息更新对应的产品服务器。采用该方法，能够根据入库的合并文件夹，对产品服务器以及执行码进行更新，实现了自动化维护版本并修改配置文件。

与上述本申请提供的一种交付方法实施例相对应的，本申请还提供了一种交付装置的实施例。

如图6所示的为本申请提供的一种交付装置实施例1的结构示意图，该装置包括以下结构：基线模块601、构建模块602、合并模块603、分配模块604和存储模块605；

其中，该基线模块601，用于基于从开发基线接收到的版本发布申请，将完成程序的源码迁入组装基线；

其中，该构建模块602，用于触发所述组装基线根据所述源码构建执行码，得到执行码组件文件；

其中，该合并模块603，用于将所述执行码组件文件与预设输入相关文件进行版本合并，得到合并文件夹；

其中，该分配模块604，用于依据预设的执行码依赖关系，对所述合并文件夹分配版本号信息，记录所述合并文件夹与所述版本号信息的对应关系；

其中，该存储模块605，用于将所述合并文件夹迁入预设存储位置，并记录所述版本号信息与存储位置的对应关系。

综上，本申请提供了一种交付装置，能够从开发基线获取源码并迁入组装基线以实现组装基线自动构件执行码，并进行分配版本号以及迁入存储位置，实现自动交付的过程，解决了现有技术中容易出现误操作以及版本交付速度低的问题。

如图7所示的为本申请提供的一种交付装置实施例2的结构示意图，该装置包括以下结构：基线模块701、构建模块702、合并模块703、分配模块704、审查模块705和存储模块706；

其中，该基线模块701、构建模块702、合并模块703、分配模块704、存储模块706的结构功能与实施例1中的相应结构功能一致，本实施例中不做赘述。

其中，该审查模块705，用于依据预设的审查规则，对所述源码进行审查；

并基于审查结果为通过，触发所述存储模块。

综上，本实施例提供的一种交付装置中，还包括：审查模块，该装置能够在将合并文件夹迁入预设存储位子之前，对源码进行审查，提高准确程度。

如图8所示的为本申请提供的一种交付装置实施例3的结构示意图，该装置包括以下结构：基线模块801、构建模块802、合并模块803、分配模块804、存储模块805、审查模块806和接收模块807；

其中，基线模块801、构建模块802、合并模块803、分配模块804、存储模块805、审查模块806的结构功能与实施例2中的相应结构功能一致，本实施例中不做赘述。

其中，该接收模块807，用于接收所述版本发布申请以及包含版本信息的文档；以及接收入库操作信息；

则所述存储模块805还用于，在所述接收模块接收到入库操作信息时，将满足预设允许出库条件的合并文件夹迁入预设出库存储区域。

综上，本实施例提供的一种交付装置中还包括接收模块，能够与外部进行信息交互，能够为后续步骤中根据该版本发布申请将源码从开发基线迁入组装基线，并为进行版本合并的过程提供依据。以及通过版本管理人员指示的入库操作，将其中满足允许出库条件的合并文件夹迁入出库存储区域中，做好出库的准备。

如图9所示的为本申请提供的一种交付装置实施例4的结构示意图，该装置包括以下结构：基线模块901、构建模块902、合并模块903、分配模块904、审查模块905、存储模块906、接收模块907和显示模块908、操作模块909以及更新模块910。

其中，基线模块901、构建模块902、合并模块903、分配模块904、审查模块905、存储模块906的结构功能与实施例3中的相应结构功能一致，本实施例中不做赘述。

其中，该显示模块908，用于对应用所述交付装置的生产线中的相关信息进行显示；

其中，该操作模块909，用于接收运行维护人员输入的操作信息，所述操作信息表征运行维护人员结合显示界面中的显示内容执行的修改操作和/或维护操作；

其中，该更新模块910，根据所述操作信息对所述产品服务器进行配置文件更新和/或维护，或者根据所述操作信息将所述合并文件夹中执行码组件对所述产品服务器的版本进行更新。

综上，本实施例提供的一种交付装置，还包括：显示模块、操作模块以及更新模块，能够根据入库的合并文件夹，对产品服务器以及执行码进行更新，实现了自动化维护版本并修改配置文件。

与上述本申请提供的一种交付方法和装置实施例相对应的，本申请还提供了一种交付方法的具体使用场景。

如图10所示的为交付方法的使用场景示意图，该场景中包括三个分区：TFS1001、目标产品应用环境1002和SADP1003。其中，该TFS分区中包括开发人员1001-1、TFS服务器1001-2、自动构件目标FTP(File Transfer Protocol，是互联网上提供文件传输、存储、访问的计算机服务器)1001-3；该目标产品应用环境1002包括若干服务器A、B、C……N；SADP1003中包括SADP开发端用户1003-1、应用服务器1003-2、版本服务器1003-3、数据库服务器1003-4和1003-5、产品库版本交付服务器1003-6、应用服务器1003-7以及SADP运维端用户1003-8。

其中，开发人员将开发的源码上传给TFS服务器1001-2，经过自动构建模块FTP服务器1001-3构建的结果(执行码组件文件)上传给版本服务器1003-3；SADP开发端用户将开发的源码上传给应用服务器，应用服务器分别发送给版本服务器以及数据库服务器，该版本服务器将源码发送给版本审查产品库1004(简称产品库)，产品库将通过审查的源码发送给产品库版本交付服务器；SADP运维端用户将运维条件输入应用服务器，应用服务器与目标产品应用环境中的服务器A-N之间通过监控与反馈机制进行数据交互，该应用服务器将运维条件分别发送给产品库版本交付服务器以及数据库服务器；该产品库版本交付服务器与目标产品应用环境中的多个服务器之间具有数据交互。

其中，上述的数据交互方式可以包括以下两种：1.WINDOWS系统中的文件操作(拷贝、复制、粘贴)2.WINDOWS系统中的PowerShell命令执行。(PowerShell：一种WINDOWS命令行外壳程序和脚本环境，可以用来执行命令行脚本)。

需要说明的是，该TFS-SADP(开发端)-版本审查产品库-SADP(部署端)-目标部署服务服务器A-N之间，是以交付的版本文件以及文档作为关联的唯一数据。

图11所示的为该交付方法中涉及的TFS与SADP-WIN的结构功能示意图。

其中，该TFS1101具有如下功能：基线管理、自动集成、自动构建、代码查看、电子看板以及自动测试，并且，该TFS中还有执行码自动构建目标服务器。

具体的，该TFS工具应涵盖在开发过程中各类管理与流程要求。如在开发阶段应包含对源码基线的管理工具；在源码迁入后，包含自动转发的代码审查机制；代码迁入后的自动集成与构建；同时包含代码的自动测试；与开发过程中的流程管理与控制如电子看板等。

其中，该SADP-WIN1102具有如下两个模块：开发支付模块和生产运维模块，并且，该SADP-WIN中还具有存储参数数据的区域1203。该开发交付模块具有如下功能：用户管理、产品管理、项目管理、版本管理、流程控制以及版本合并，并且，该开发交付模块中还具有版本服务器；该生产运维模块具有如下功能：CI(Continuous Intergration，持续集成)仪表盘、参数配置、版本部署以及数据工厂。

该SADP-WIN应适配windows生产线上的所有产品，实现开发端到运维端的全流程自动交付。

其中，该SADP-WIN的功能具体解释如下：

用户管理：管理用户类型，分为开发人员、产品库人员、运维人员、管理员类型。根据用户类型包含不同的功能。

产品管理：对使用SADP-WIN的产品进行管理，包括产品名称、产品信息简介，分产品的版本管理

项目管理：主要对各产品的项目进行管理，包括项目基本信息管理、跟踪批次管理、项目版本号申请

版本管理：分产品、分项目、分批次对产品执行码进行管理

流程控制：SADP服务器程序逻辑处理与流程定义模块，包含版本申请流程的控制、版本合并规则控制执行码交付流程等。

版本合并：分产品分批次对入库执行码进行合并工作，形成全量的资产均线管理工作。

参数配置：主要包含产品级配置文件的参数化配置、部署目标服务器地址配置等。

参数配置具体包括：开发部门针对WIN生产线中产品所包含的配置项进行归纳总结，整理出全量配置文件及配置项点；运维人员首先对WIN生产线中产品各服务器类型中包含的各服务器地址及站点物理地址进行配置；分服务器种类、分配置文件形成可视化前端网页配置方式，对于同一配置点可在前端进行统一配置，在配置界面可针对服务器进行服务器特殊化配置，同时支持无差异的统一配置。

版本部署：实现运维人员对版本合并后，与参数配置后的配置文件自动合并为各服务器镜像，自动化部署目标应用服务器。并建立起部署健康检查反馈机制。

版本部署中包含版本更新后对应应用程序、Windows服务、IIS(InternetInformation Service由微软公司提供的互联网信息服务)站点等自动重启生效机制。

CI仪表盘：实现对生产运维数据的实时监控，具体实施中还依靠运维人员对当前生产环境中所需重点关注且的监控点进行反馈。该仪表盘着重于WIN生产线上应用的监控，如新增交易的执行频率、应用服务器上交易并发量、交易各阶段响应时间等。

数据工厂：主要包含对产品级生产数据的收集加工反馈功能，具体可以包括对于目前生产环境中已存在的数据加工与分析项进行整理，梳理出改进与增加点。

如图12所示的为使用场景中显示界面的示意图，包括：标题区域1201以及内容区域1202；其中，该标题区域中的标题是“参数维护界面”。其中(a)中内容区域中最初显示的为“模块选择”其中具有多个选项，选择“工作流”选项，(b)中内容区域中显示的为“工作流”以及其相应的信息“选择配置文件”，其具有多个选项，选择“WEB.CONFIG”选项，(c)中内容区域中显示的为“工作流”、“WEB.CONFIG”以及其相应的信息“选择配置点”，其具有多个选项，选择“BLCONFIG地址”选项，(d)中内容区域中显示的为“工作流”、“WEB.CONFIG”、“BLCONFIG地址”以及ABCDEF服务器及其对应的BLCONFIG地址1-6、“统一修改点：”、“BLCONFIG地址N”、“提交按钮”以及“统一修改提交按钮”。

本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例提供的装置而言，由于其与实施例提供的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。

对所提供的实施例的上述说明，使本领域专业技术人员能够实现或使用本申请。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下，在其它实施例中实现。因此，本申请将不会被限制于本文所示的这些实施例，而是要符合与本文所提供的原理和新颖特点相一致的最宽的范围。

Claims (10)

1.一种交付方法，其特征在于，包括：

基于从开发基线接收到的版本发布申请，将完成程序的源码迁入组装基线；

触发所述组装基线根据所述源码构建执行码，得到执行码组件文件，所述执行码组件文件中包含有执行码，所述执行码是在程序运行过程中能够完成程序所要求的功能逻辑时，机器能够执行的代码；

将所述执行码组件文件与包含版本信息的文档进行版本合并，得到合并文件夹；

依据预设的执行码依赖关系，对所述合并文件夹分配版本号信息，记录所述合并文件夹与所述版本号信息的对应关系；

将所述合并文件夹迁入预设存储位置，并记录所述版本号信息与存储位置的对应关系，所述预设存储位置包括版本办理的路径或环境更新的路径。

2.根据权利要求1所述的方法，其特征在于，所述依据预设的执行码依赖关系，对所述合并文件夹分配版本号信息之后，所述将所述合并文件夹迁入预设存储位置之前，还包括：

依据预设的审查规则，对所述合并文件夹中的源码进行审查；

并基于审查结果为通过，执行所述将所述合并文件夹迁入预设存储位置步骤。

3.根据权利要求1所述的方法，其特征在于，所述基于从开发基线接收到的版本发布申请，将完成程序的源码迁入组装基线之前，还包括：

接收所述版本发布申请以及包含版本信息的文档。

4.根据权利要求1所述的方法，其特征在于，所述将所述合并文件夹迁入预设存储位置之后，还包括：

根据接收到的入库操作信息，将满足预设允许出库条件的合并文件夹迁入预设出库存储区域。

5.根据权利要求4所述的方法，其特征在于，所述将满足预设允许出库条件的合并文件夹迁入预设出库存储区域之后，还包括：

根据输入的运行维护条件，分析得到与所述运行维护条件对应的第一版本号信息；

获取与所述第一版本号信息对应的合并文件夹；

依据所述合并文件夹中的版本信息更新对应的产品服务器。

6.根据权利要求5所述的方法，其特征在于，接收输入的运行维护条件包括：

接收运行维护人员输入的操作信息，所述操作信息表征运行维护人员结合显示界面中的显示内容执行的修改操作和/或维护操作；

则所述依据所述合并文件夹中的版本信息更新对应的产品服务器，具体包括：

根据所述操作信息对所述产品服务器进行配置文件更新和/或维护；

或者

根据所述操作信息将所述合并文件夹中执行码组件对所述产品服务器的版本进行更新。

7.一种交付装置，其特征在于，包括：

基线模块，用于基于从开发基线接收到的版本发布申请，将完成程序的源码迁入组装基线；

构建模块，用于触发所述组装基线根据所述源码构建执行码，得到执行码组件文件，所述执行码组件文件中包含有执行码，所述执行码是在程序运行过程中能够完成程序所要求的功能逻辑时，机器能够执行的代码；

合并模块，用于将所述执行码组件文件与预设输入相关文件进行版本合并，得到合并文件夹；

分配模块，用于依据预设的执行码依赖关系，对所述合并文件夹分配版本号信息，记录所述合并文件夹与所述版本号信息的对应关系；

存储模块，用于将所述合并文件夹迁入预设存储位置，并记录所述版本号信息与存储位置的对应关系，所述预设存储位置包括版本办理的路径或环境更新的路径。

8.根据权利要求7所述的装置，其特征在于，还包括：

审查模块，用于依据预设的审查规则，对所述源码进行审查；

并基于审查结果为通过，触发所述存储模块。

9.根据权利要求8所述的装置，其特征在于，还包括：

接收模块，用于接收所述版本发布申请以及包含版本信息的文档，以及接收入库操作信息；

所述存储模块，还用于在所述接收模块接收到入库操作信息时，将满足预设允许出库条件的合并文件夹迁入预设出库存储区域。

10.根据权利要求9所述的装置，其特征在于，还包括：

显示模块，用于对应用所述交付装置的生产线中的相关信息进行显示；

操作模块，用于接收运行维护人员输入的操作信息，所述操作信息表征运行维护人员结合显示界面中的显示内容执行的修改操作和/或维护操作；

更新模块，根据所述操作信息对产品服务器进行配置文件更新和/或维护，或者根据所述操作信息将所述合并文件夹中执行码组件对所述产品服务器的版本进行更新。

Images