灰度发布的方法及设备与流程

本申请涉及通信及计算机领域，尤其涉及一种灰度发布的方法及设备。

背景技术：

数据库管理员(DataBASE Administrator，简称DBA)在灰度发布时,因涉及的业务线广泛,不仅需要分发的任务多,而且受管理的服务器数量庞大,每次分发任务执行时,因灰度发布需要分批验证,时间较长,如果这时还有其他的分发任务,不能多任务并发，通常只能采用如下两种串行的分发方式进行发布：

(1)等上一个分发任务完成并验证通过后,再来执行下一个分发任务；

(2)在发布之前需要收集所有发布请求并进行合并,一旦合并完成并开始发布后,无法在中途再加其他发布请求,除非上一次任务发布完成并确认后再发布新的请求,或者回退至上一个正在执行的灰度任务,再把新请求重新合并后发布。

但是，上述串行的分发方式存在效率低下的问题。

技术实现要素：

本申请的目的是提供一种灰度发布的方法及设备，能够实现多个任务执行路径可以同时并发进行灰度发布。

有鉴于此，本申请提供一种灰度发布的方法，

将新的灰度发布任务和旧的灰度发布任务的配置项存放于目录中，其中，所述新的灰度发布任务和旧的灰度发布任务经冲突检查合格；

根据目录及其配置项生成新的和旧的灰度发布任务的所有候选的任务执行路径；

根据每个服务器的灰度发布任务的执行进度和每个灰度发布任务的分发批次，从所有候选的任务执行路径中选择最优的任务执行路径作为修改后的元数据向对应服务器发送，其中，所述元数据包括服务器地址、该服务器对应使用的目录和相应的配置项的编号。

进一步的，上述方法中，从所有候选的任务执行路径中选择最优的任务执行路径作为修改后的元数据向对应服务器发送之后，还包括：

每个服务器根据接收到的所述元数据完成配置。

进一步的，上述方法中，当新的和旧的灰度发布任务是修改原始的目录中的配置项时，将新的和旧的灰度发布任务的配置项存放于目录中，包括：

每有一个新的灰度发布任务，则复制一个原始的目录作为新的目录，根据每个灰度发布任务对相应新的目录中的待修改配置项进行修改，得到修改后的配置项；

从所有候选的任务执行路径中选择最优的任务执行路径作为修改后的元数据向对应服务器发送中，

所述元数据包括服务器地址、该服务器对应使用的新的目录和该新的目录中相应的修改后的配置项的编号。

进一步的，上述方法中，每个服务器根据接收到的所述元数据完成配置之后，还包括：

备份原始的目录和所有新的目录后删除该原始的目录和所有新的目录；

以所有新的目录的合并作为新的原始的目录；

修改元数据，所述元数据包括服务器地址、该服务器对应使用的新的原始的目录和该新的原始的目录中相应的修改后的配置项的编号。

进一步的，上述方法中，从所有候选的任务执行路径中选择最优的任务执行路径作为修改后的元数据向对应服务器发送的同时，所述方法还包括：

暂停向服务器发送元数据；

修改元数据至不包含待回退的灰度发布任务的状态后，将修改后的元数 据向对应服务器发送；

若某个服务器根据原先接收到的所述元数据已经完成配置，则该服务器根据接收到的修改后的元数据完成回退配置。

进一步的，上述方法中，当新的和旧的灰度发布任务是增加原始的目录中的配置项时，将新的灰度发布任务和旧的灰度发布任务的配置项存放于目录中，包括：

每有一个新的旧的灰度发布任务，则根据每个灰度发布任务将待增加的配置项加入所述原始的目录中；

从所有候选的任务执行路径中选择最优的任务执行路径作为修改后的元数据向对应服务器发送中，

所述元数据包括服务器地址、该服务器使用的原始的目录和该原始的目录中相应的待增加配置项的编号。

进一步的，上述方法中，每有一个新的旧的灰度发布任务，则根据每个灰度发布任务将待增加的配置项加入所述原始的目录中之前，还包括：

备份原始的目录。

进一步的，上述方法中，从所有候选的任务执行路径中选择最优的任务执行路径作为修改后的元数据向对应服务器发送的同时，所述方法还包括：

暂停向服务器发送元数据；

在原始的目录中添加一个对应于原先新增的配置项的反安装配置项，所述反安装配置项用于删除该目录中对应的原先新增的配置项；

修改元数据并向对应服务器发送，修改后的元数据包括服务器地址、该服务器使用的原始的目录和该原始的目录中替换原先新增的配置编号的反安装配置项的编号；

若某个服务器根据原先接收到的所述元数据已经完成配置，则该服务器根据接收到的修改后的元数据完成回退配置。

进一步的，上述方法中，服务器根据接收到的修改后的元数据完成回退 配置之后，还包括：

备份原始的目录中的原先新增的配置项和对应的反安装配置项后，删除该原先新增的配置项和对应的反安装配置项，删除元数据中的反安装配置项的编号。

进一步的，上述方法中，当新的和旧的灰度发布任务是删除原始的目录中的配置项时，将新的灰度发布任务和旧的灰度发布任务的配置项存放于目录中，包括：

每有一个新旧的灰度发布任务，则根据每个灰度发布任务在原始的目录中分别对应增加一个反安装配置项，所述反安装配置项用于删除该目录中对应的待删除的配置项；

从所有候选的任务执行路径中选择最优的任务执行路径作为修改后的元数据向对应服务器发送中，

所述元数据包括服务器地址、该服务器使用的原始的目录和该原始的目录中替换待删除的配置项的编号的反安装配置项的编号。

进一步的，上述方法中，每有一个新旧的灰度发布任务，则根据每个灰度发布任务在原始的目录中分别对应增加一个反安装配置项之前，还包括：

备份原始的目录。

进一步的，上述方法中，每个服务器根据接收到的所述元数据完成配置的步骤之后，还包括：

备份原始的目录中的待删除的配置项和对应的反安装配置项后，将待删除的配置项和对应反安装配置项从原始的目录中删除；

将元数据中的每个服务器对应使用的原始的目录中反安装配置项的对应配置项的编号删除。

进一步的，上述方法中，从所有候选的任务执行路径中选择最优的任务执行路径作为修改后的元数据向对应服务器发送的同时，还包括：

暂停向服务器发送元数据；

在原始的目录中添加一个对应于原先的反安装配置项的新增的配置项；

修改元数据并向对应服务器发送，修改后的元数据包括服务器地址、该服务器使用的原始的目录和该原始的目录中替换原先的反安装配置项的编号的新增的配置项的编号；

若某个服务器根据原先接收到的所述元数据已经完成配置，则该服务器根据接收到的修改后的元数据完成回退配置。

进一步的，上述方法中，服务器根据接收到的修改后的元数据完成回退配置之后，还包括：

删除所述原始的目录中的原先的反安装配置项。

根据本申请的另一面不提供一种灰度发布的设备，包括：

第一装置，用于将新的灰度发布任务和旧的灰度发布任务的配置项存放于目录中，其中，所述新的灰度发布任务和旧的灰度发布任务经冲突检查合格；

第二装置，用于根据目录及其配置项生成新的和旧的灰度发布任务的所有候选的任务执行路径；

第三装置，用于根据每个服务器的灰度发布任务的执行进度和每个灰度发布任务的分发批次，从所有候选的任务执行路径中选择最优的任务执行路径作为修改后的元数据向对应服务器发送，其中，所述元数据包括服务器地址、该服务器对应使用的目录和相应的配置项的编号。

进一步的，上述设备中，所述设备还包括：

第四装置，用于在所述第三装置执行之后，控制每个服务器根据其接收到的所述元数据完成配置。

进一步的，上述设备中，当新的和旧的灰度发布任务是修改原始的目录中的配置项时，

所述第一装置，用于每有一个新的灰度发布任务，则复制一个原始的目录作为新的目录，根据每个灰度发布任务对相应新的目录中的待修改配置项 进行修改，得到修改后的配置项；

所述第三装置向对应服务器发送的元数据包括服务器地址、该服务器对应使用的新的目录和该新的目录中相应的修改后的配置项的编号。

进一步的，上述设备中，所述设备还包括第五装置，用于在所述第四装置执行之后，

备份原始的目录和所有新的目录后删除该原始的目录和所有新的目录；

以所有新的目录的合并作为新的原始的目录；

修改元数据，所述元数据包括服务器地址、该服务器对应使用的新的原始的目录和该新的原始的目录中相应的修改后的配置项的编号。

进一步的，上述设备中，所述设备还包括第六装置，用于在所述第三装置执行的同时，

暂停向服务器发送元数据；

修改元数据至不包含待回退的灰度发布任务的状态后，将修改后的元数据向对应服务器发送；

若某个服务器根据原先接收到的所述元数据已经完成配置，则该服务器根据接收到的修改后的元数据完成回退配置。

进一步的，上述设备中，当新的和旧的灰度发布任务是增加原始的目录中的配置项时，

所述第一装置，用于每有一个新的旧的灰度发布任务，则根据每个灰度发布任务将待增加的配置项加入所述原始的目录中；

所述第三装置向对应服务器发送的元数据包括服务器地址、该服务器使用的原始的目录和该原始的目录中相应的待增加配置项的编号。

进一步的，上述设备中，所述设备还包括第七装置，用于在所述第一装置执行之前，备份原始的目录。

进一步的，上述设备中，所述设备还包括第八装置，用于在所述第三装置执行的同时，

暂停向服务器发送元数据；

在原始的目录中添加一个对应于原先新增的配置项的反安装配置项，所述反安装配置项用于删除该目录中对应的原先新增的配置项；

修改元数据并向对应服务器发送，修改后的元数据包括服务器地址、该服务器使用的原始的目录和该原始的目录中替换原先新增的配置编号的反安装配置项的编号；

若某个服务器根据原先接收到的所述元数据已经完成配置，则该服务器根据接收到的修改后的元数据完成回退配置。

进一步的，上述设备中，所述设备还包括第九装置，用于在所述第八装置执行之后，备份原始的目录中的原先新增的配置项和对应的反安装配置项后，删除该原先新增的配置项和对应的反安装配置项，删除元数据中的反安装配置项的编号。

进一步的，上述设备中，当新的和旧的灰度发布任务是删除原始的目录中的配置项时，

所述第一装置，用于每有一个新旧的灰度发布任务，则根据每个灰度发布任务在原始的目录中分别对应增加一个反安装配置项，所述反安装配置项用于删除该目录中对应的待删除的配置项；

所述第三装置向对应服务器发送的元数据包括服务器地址、该服务器使用的原始的目录和该原始的目录中替换待删除的配置项的编号的反安装配置项的编号。

进一步的，上述设备中，所述设备还包括第十装置，用于在所述第一装置执行之前，备份原始的目录。

进一步的，上述设备中，所述设备还包括第十一装置，用于在所述第四装置执行之后，备份原始的目录中的待删除的配置项和对应的反安装配置项后，将待删除的配置项和对应反安装配置项从原始的目录中删除；以及将元数据中的每个服务器对应使用的原始的目录中反安装配置项的对应配置项的 编号删除。

进一步的，上述设备中，所述设备还包括第十二装置，用于在所述第三装置执行的同时，

暂停向服务器发送元数据；

在原始的目录中添加一个对应于原先的反安装配置项的新增的配置项；

修改元数据并向对应服务器发送，修改后的元数据包括服务器地址、该服务器使用的原始的目录和该原始的目录中替换原先的反安装配置项的编号的新增的配置项的编号；

若某个服务器根据原先接收到的所述元数据已经完成配置，则该服务器根据接收到的修改后的元数据完成回退配置。

进一步的，上述设备中，所述设备还包括第十三装置，用于在所述第十二装置执行之后，删除所述原始的目录中的原先的反安装配置项。

与现有技术相比，本申请根据每个服务器的灰度发布任务的执行进度和每个灰度发布任务的分发批次，从所有候选的任务执行路径中选择最优的任务执行路径作为修改后的元数据向对应服务器发送，达到多个任务执行路径可以同时并发进行灰度发布的效果，即在一个或者多个灰度发布任务执行中时,可再加入新的灰度发布请求，按分发批次选择最优的任务执行路径,同时保证任务与任务之间相互不干扰，大大加快了分发配置的速度。

进一步的，当新的和旧的灰度发布任务是修改原始的目录中的配置项时，每有一个新的灰度发布任务，则复制一个原始的目录作为新的目录，根据每个灰度发布任务对相应新的目录中的待修改配置项进行修改，得到修改后的配置项，所述元数据包括服务器地址、该服务器对应使用的新的目录和该新的目录中相应的修改后的配置项的编号，实现多个修改原始的目录中的配置项的灰度发布任务能够同时进行。

进一步的，当新的和旧的灰度发布任务是修改原始的目录中的配置项时，通过备份原始的目录和所有新的目录以防有回退要求时,可以快速恢复目 录，及备份后删除该原始的目录和所有新的目录，避免有多个环境存在而且产生干扰；通过以所有新的目录的合并作为新的原始的目录，以方便复位,为下一次灰度发布任务准备相对干净无干扰的环境。

进一步的，新的和旧的灰度发布任务是增加原始的目录中的配置项时，通过每有一个新的旧的灰度发布任务，则根据每个灰度发布任务将待增加的配置项加入所述原始的目录中，所述元数据包括服务器地址、该服务器使用的原始的目录和该原始的目录中相应的待增加配置项的编号，实现多个增加原始的目录中的配置项的灰度发布任务能够同时进行。

进一步的，通过在将待增加的配置项加入所述原始的目录中的步骤之前，备份原始的目录，以便后续需要回退的情况发生时，能够顺利地回退到的新增前的BASE环境。

进一步的，新的和旧的灰度发布任务是删除原始的目录中的配置项时，通过每有一个新旧的灰度发布任务，则根据每个灰度发布任务在原始的目录中分别对应增加一个反安装配置项，所述反安装配置项用于删除该目录中对应的待删除的配置项，所述元数据包括服务器地址、该服务器使用的原始的目录和该原始的目录中替换待删除的配置项的编号的反安装配置项的编号，实现多个删除原始的目录中的配置项的灰度发布任务能够同时进行。

进一步的，通过在在原始的目录中分别对应增加一个反安装配置项之前，备份原始的目录，以便后续需要回退的情况发生时，能够顺利地回退到的新增前的BASE环境；通过在每个服务器根据接收到的所述元数据完成配置的步骤之后，备份原始的目录中的待删除的配置项和对应的反安装配置项，以便后续可能回退的需要，然后将待删除的配置项和对应反安装配置项从原始的目录中删除，将元数据中的每个服务器对应使用的原始的目录中反安装配置项的对应配置项的编号删除，以去掉不必要的配置项,保持最终状态的目录中配置项无相互矛盾的情况。

进一步的，通过在从所有候选的任务执行路径中选择最优的任务执行路 径作为修改后的元数据向对应服务器发送的同时，对修改、增加、删除原始的目录中的配置项的新的和/或旧的灰度发布任务进行回退，实现即使灰度发布任务执行错误，可以进行快速准确的回退。

附图说明

通过阅读参照以下附图所作的对非限制性实施例所作的详细描述，本申请的其它特征、目的和优点将会变得更明显：

图1示出根据本申请一个方面的灰度发布的方法流程图；

图2示出本申请的一优选的实施例灰度发布的方法流程图；

图3示出本申请的一实施例灰度发布的方法一个灰度发布任务执行路径图；

图4示出本申请的一实施例灰度发布的方法二个任务同时灰度发布任务执行路径图；

图5示出本申请的一实施例灰度发布的方法三个任务同时灰度发布任务执行路径图；

图6示出本申请的一实施例灰度发布的方法三个任务同时灰度发布任务执行路径图；

图7示出本申请的一较佳的实施例灰度发布的方法流程图；

图8示出本申请的另一优选的实施例灰度发布的方法流程图；

图9示出本申请的又一优选的实施例灰度发布的方法流程图；

图10示出本申请的再一优选的实施例灰度发布的方法流程图；

图11示出本申请的另一较佳的实施例灰度发布的方法流程图；

图12示出根据本申请另一个方面的灰度发布的设备示意图；

图13示出根据本申请另一优选的实施例灰度发布的方法设备示意图；

图14示出根据本申请又一优选的实施例灰度发布的方法设备示意图；

图15示出根据本申请再一优选的实施例灰度发布的方法设备示意图；

图16示出根据本申请一较佳的实施例灰度发布的方法设备示意图；

图17示出根据本申请另一较佳的实施例灰度发布的方法设备示意图；

图18示出根据本申请又一较佳的实施例灰度发布的方法设备示意图；

图19示出根据本申请再一较佳的实施例灰度发布的方法设备示意图；

图20示出根据本申请另一优选的实施例灰度发布的方法设备示意图；

图21示出根据本申请又一优选的实施例灰度发布的方法设备示意图；

图22示出根据本申请再一优选的实施例灰度发布的方法设备示意图；

附图中相同或相似的附图标记代表相同或相似的部件。

具体实施方式

在本申请一个典型的配置中，终端、服务网络的设备和可信方均包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括非暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

如图1所示，本申请提供一种灰度发布的方法，包括：

步骤S1，将新的灰度发布任务和旧的灰度发布任务的配置项(state)存放于目录(environment)中，其中，所述旧的和新的灰度发布任务是在时间上相对而言的灰度发布任务，如产生时间上较新的则为新的灰度发布任务，如产生时间上较旧的则为旧的灰度发布任务，在一个时刻上的新的灰度发布，如果下一时刻有更新的灰度发布任务，则原来新的灰度发布任务在该时刻则成为了旧的灰度发布任务，另外，所述新的灰度发布任务和旧的灰度发布任务经冲突检查合格，从而保证后续并行执行的灰度发布任务和旧的灰度发布任务发生冲突，若同时有多个新的灰度发布任务产生，则新的灰度发布任务之间也需要经冲突检查合格，新的灰度发布任务可以是对原始的目录的改动，如对原始的目录(BASE)中的配置项进行修改、增加和删除；

步骤S2，根据目录及其配置项生成新的和旧的灰度发布任务的所有候选的任务执行路径，即对新的灰度发布任务和旧的灰度发布任务的进行任意排列组合生成所有候选的任务执行路径，其中，每个旧的灰度发布任务或新的灰度发布任务的执行完成是通过其目录中的配置项对服务器进行配置，每个任务执行路径用于执行旧的灰度发布任务和/或新的灰度发布任务；

步骤S3，根据每个服务器的灰度发布任务的执行进度和每个灰度发布任务的分发批次，从所有候选的任务执行路径中选择最优的任务执行路径作为修改后的元数据向对应服务器发送，其中，所述元数据包括服务器地址如IP地址、该服务器对应使用的目录(environment)和相应的配置项(state)编号，一个配置项的编号与一个配置项对应。具体的，比如现在有10000台数据库服务器需要更新某个配置项A,为确保线上稳定需要将分发批次分为10批进行灰度发布,每一批1000台，开始对应的生成灰度发布任务1，假设现在已推送完5批,并且其中4批灰度发布任务1的服务机机主(owner)已确认通过,第5批还在确认中,这时接到第二个分发任务,需要升级10000台数据库服务器的某个软件包B,通过检查配置文件A和软件B无冲突后,生成灰度发布任 务2,同样分发批次分10批进行灰度发布,可以根据旧的灰度发布任务(任务1)的执行进度(旧的灰度发布任务1可能在有些服务器上已经执行，也有可能未执行)和每个灰度发布任务1、2的分发批次为每个服务器选择对应任务执行路径，如部分服务器已经执行任务1的则再执行任务2，同时，部分服务器还未执行任务1的，将任务1和任务2同时执行，或者考虑到分发批次的问题，部分服务器先执行作任务2再执行任务1，或者先执行任务1再执行任务2，从而实现任务1和任务2可以在不同时的服务器上同时进行执行,并且如果任务1需要回退,由于各任务之间通过冲突检查合格，回退时，也不会影响任务2的继续执行。以此类推,如果再接收到任务3,任务4…任务N都可以同时执行,相互不影响,不冲突。又如，有10000台服务器,A任务要求对这10000台服务器的分发批次为分5批执行,每批执行2000台服务器,然后，又有B任务要求对同样这10000台服务器的分发批次为分20批执行,每次只执行500台服务器，此时，若有有gay A(只执行任务A),gay B(只执行任务B),gay AB(同时执行任务AB)三个候选的任务执行路径,A任务2000台一批,B任务500台一批,那么如果从里面选出2000台从没执行过这两个任务的机器,那按最优化的任务执行路径,那就会有1500台走到gay A,有500台走到gay AB。在此，可通过使用如saltstack的配置管理工具中通用的目录(environment)和配置项(state),所述元数据可以存放于一个文件中,也可以存放于数据库里的一张或者多张表中，例如可以配合使用MySQL数据库存放服务器的元数据,达到多个任务执行路径可以同时并发进行灰度发布的效果，即在一个或者多个灰度发布任务执行中时,可再加入新的灰度发布请求，按分发批次选择最优的任务执行路径,同时保证任务与任务之间相互不干扰，大大加快了分发配置的速度。本实施例的核心思想是在有多个灰度发布任务需求时,通过生成所有可能的任务执行路径即中间目录,然后针对当前不同服务器的状态即灰度发布任务的执行进度和分发批次从中间目录中选择最优的一步任务执行路径作为元数据向对应服务器发送，从而最大限度地实现多任务同时灰度发布。 本实施例的核心思想是在有多个灰度发布任务需求时,通过生成所有可能的任务执行路径即中间目录,然后针对当前不同服务器的状态即灰度发布任务的执行进度和分发批次从所有可能的任务执行路径选择最优的一步任务执行路径作为元数据对应服务器发送,从而最大限度地实现多任务同时灰度发布。

如图2所示，本申请的一种灰度发布的方法一优选的实施例中，步骤S3之后还包括步骤S4，每个服务器根据接收到的所述元数据完成配置，从而在所有服务器上完成灰度发布。

本申请的一种灰度发布的方法一优选的实施例中，当新的和旧的灰度发布任务是修改原始的目录(environment中的BASE)中的配置项时，

步骤S1，将新的和旧的灰度发布任务的配置项存放于目录中，包括：

每有一个新的灰度发布任务，则复制一个原始的目录(BASE)作为新的目录(GAY A、GAY B、GAY C……)，根据每个灰度发布任务对相应新的目录中的待修改配置项进行修改，得到修改后的配置项；在此，把最原始状态的目录(environment)称为BASE(a b c),当接收到新的灰度发布任务gay A(a'b c)时，即对目录中的a配置项进行修改，则会先从原来的BASE(a b c)复制生成一个新的environmentg为gay A(a b c)，并把gay A里面的配置项a按最新的要求去修改生成gay A(a'b c)，新的灰度发布任务gay A(a'b c)执行时,若接收到另一个新的灰度发布任务gay B(a b'c)要求修改配置项b,这时又会在原来的BASE(a b c)基础上再生成一个新的environment为gay B(a b'c)；

相应的，步骤S2，根据目录及基配置项对新的灰度发布任务和旧的灰度发布任务的进行任意排列组合生成所有可能的任务执行路径(分发目录)中，如图3所示，若原来的分发目录为(BASE(1 2 3))，在增加新的灰度发布任务gay A时，分发目录修改为(BASE(1 2 3),gay A(1'2 3))，同理，当又接收到新的灰度发布 任务时gay B时，如图4所示，分发目录修改为(BASE(1 2 3),gay A(1'2 3),gay B(1 2'3),gay AB(1'2'3))，三个任务同时灰度发布的分发目录如图5所示，四个任务同时灰度发布的分发目录如图6所示，依此类推，通过复制BASE目录以及生成对不同任务组合过的中间状态environment即所有候选的任务执行路径,并在加入新分发任务时对执行路径进行修改即生成新的所有候选的任务执行路径,最终达到所有任务一致的状态,完成所有分发任务的灰度发布,即使同时进行更多的任务灰度发布,通过本实施例都可以完成.当然,随着同时执行的任务越多,中间environment(gay A，gay B…)的生成会越多,执行路径会更加复杂；

相应的，步骤S3，根据每个服务器灰度发布任务的执行进度和每个灰度发布任务的分发批次，从所有候选的任务执行路径中选择最优的任务执行路径作为修改后的元数据向对应服务器发送的步骤中，

所述元数据包括服务器地址、该服务器对应使用的新的目录和该新的目录中相应的修改后的配置项的编号。在此，新的目录是相对于原始的目录来说的，每产生一个新的修改原始的目录的配置灰度发而任务，则对应会生成一个新的目录，各新的目录的产生在时间上可能有先后关系，但各新的目录之间不存在新旧关系的概念，其可能是新的灰度发布任务的新的目录，也可能是旧的灰度发布任务的新的目录，但各新的目录相对原始的目录来说都是的新的目录。例如，接收到gay A前原来的元数据为machine X-->BASE-->【1】,【2】,【3】，在接收到gay A后，元数据修改为machine X-->gay A-->【1】,【2】,【3】，同理，当又接收到新的灰度发布任务时gay B时，已经执行完gay A的服务器还需要进行分发任务gay B,尚未执行任何任务的机器需要按批次进行gay AB发布，例如，可将未执行gay A的服务器X的元数据又进一步由machine X-->gay A-->【1】,【2】,【3】修改为 machine X-->gay AB-->【1】,【2】,【3】，同时，考虑到批次的问题，同时将服务器Y的元数据由原来的元数据machine Y-->BASE-->【1】,【2】,【3】修改为machine Y-->gay a/gay b/gay AB-->【1】,【2】,【3】，即m achine Y-->gay A--gay AB-->【1】,【2】,【3】，或者machine Y-->gay B--gay AB-->【1】,【2】,【3】，或者machine Y-->gay AB-->【1】,【2】,【3】。

如图7所示，本申请的一种灰度发布的方法一较佳的实施例中，当新的和旧的灰度发布任务是修改原始的目录(environment中的BASE)中的配置项时，步骤S4，每个服务器根据接收到的所述元数据完成配置的步骤之后，还包括：

步骤S411，备份原始的目录和所有新的目录后删除该原始的目录和所有新的目录；在此，需要备份所有中间状态环境即原始的目录和所有新的目录,以防有回退要求时,可以快速恢复目录，备份后即可以删除,避免有多个环境存在而且产生干扰；

步骤S412，以所有新的目录的合并作为新的原始的目录，在此，需要复制最终状态的目录作为原始的目录(BASE),以方便复位,为下一次灰度发布任务准备相对干净无干扰的环境，例如，第一个灰度发布任务gay A(a'b c)是修改配置项a，第二个灰度发布任务gay A(a b'c)是修改配置项b，第一个灰度发布任务gay A(a b c')是修改配置项c，则所有新的目录的合并为gay A(a'b'c')；

步骤S413，修改元数据，所述元数据包括服务器地址、该服务器对应使用的新的原始的目录和该新的原始的目录中相应的修改后的配置项的编号。步骤S411至步骤S413是在全部灰度任务完成后进行。

本申请的一种灰度发布的方法一优选的实施例中，当新的和旧的灰度发布任务是增加原始的目录中的配置项时，

步骤S1，将新的灰度发布任务和旧的灰度发布任务的配置项存放于目录中，包括：

每有一个新的旧的灰度发布任务，则根据每个灰度发布任务将待增加的配置项加入所述原始的目录中；在此，当灰度发布任务是在原始的目录中新增配置项时,并不需要像前述实施例中通过复制BASE来完成,因为增加配置项不会引起目录中的已有配置项的修改，所以只需要在原BASE中直接加入一个新配置项；

相应的，步骤S3，根据每个服务器灰度发布任务的执行进度和每个灰度发布任务的分发批次，从所有候选的任务执行路径中选择最优的任务执行路径作为修改后的元数据向对应服务器发送的步骤中，

所述元数据包括服务器地址、该服务器使用的原始的目录和该原始的目录中相应的待增加配置项的编号。在此，修改元数据中的配置项(state)内容,即加上新的state再进行推送即可，例如若BASE(1 2 3)时，对应的元数据为machine X(服务器X)-->BASE-->【1】,【2】,【3】，当要在BASE时增加的配置项A时，步骤S121中将BASE改为BASE(1 2 3 A)，然后，步骤S321中，对应将元数据修改为元数据machine X-->BASE-->【1】,【2】,【3】,【A】，这里【1】,【2】,【3】,【A】分别为对应于配置项1 2 3 A的配置项的编号，如果同时存在多个新增配置项任务,也是使用同样的方法生成元数据，例如，有两个配置项A和B要增加，根据批次和每个服务器执行进度，可同时增加A和B元数据，也可分步增加A或B的元数据，然后将元数据进行向服务器的推送。

本申请的一种灰度发布的方法一较佳的实施例中，当新的和旧的灰度发布任务是增加原始的目录(environment中的BASE)中的配置项时，步骤S1中，每有一个新的旧的灰度发布任务，则根据每个灰度发布任务将待增加的配置项加入所述原始的目录中的步骤之前，还包括：

备份原始的目录。在此，在新增配置项之前备份当前的BASE环境,是为了后续需要回退的情况发生时，能够顺利地回退到的新增前的BASE环境。

本申请的一种灰度发布的方法一优选的实施例中，当新的和旧的灰度发布任务是删除原始的目录中的配置项时，

步骤S1，将新的灰度发布任务和旧的灰度发布任务的配置项存放于目录中，包括：

每有一个新旧的灰度发布任务，则根据每个灰度发布任务在原始的目录中分别对应增加一个反安装配置项，所述反安装配置项用于删除该目录中对应的待删除的配置项；

相应的，步骤S3，根据每个服务器灰度发布任务的执行进度和每个灰度发布任务的分发批次，从所有候选的任务执行路径中选择最优的任务执行路径作为修改后的元数据向对应服务器发送的步骤中，

所述元数据包括服务器地址、该服务器使用的原始的目录和该原始的目录中替换待删除的配置项的编号的反安装配置项的编号。在此，该原始的目录中替换待删除的配置项的编号的反安装配置项的编号即，在元数据中的每个服务器使用的原始的目录中去除所述待删除的配置项的对应配置项的编号，并添加所述反安装配置项的对应配置项的编号。这里配置项的删除同样是对BASE中s tate信息进行修改,但不是直接删除,而是在中间状态新建一个反安装配置项(uninstall state),并在推送元数据前将在原来的元数据中去掉需要删除的state,加入uninstall state。

本申请的一种灰度发布的方法一较佳的实施例中，当新的旧的灰度发布任务是删除原始的目录中的配置项时，步骤S1中，每有一个新旧的灰度发布任务，则根据每个灰度发布任务在原始的目录中分别对应增加一个反安装配置项的步骤之前，还包括：

备份原始的目录，在此，在删除配置项之前备份当前的BASE环境,是为了后续需要回退的情况发生时，能够顺利地回退到的新增前的BASE环境。

如图8所示，本申请的一种灰度发布的方法一优选的实施例中，当新的旧的灰度发布任务是删除原始的目录中的配置项时，步骤S4，每个服务器根据接收到的所述元数据完成配置的步骤之后，还包括：

步骤S431，备份原始的目录中的待删除的配置项和对应的反安装配置项后，将待删除的配置项和对应反安装配置项从原始的目录中删除，在此，备份原始的目录中的待删除的配置项和对应反安装配置项是为了后续可能回退的需要，将待删除的配置项和对应反安装配置项从原始的目录中删除是为了保持最终状态的目录中配置项无相互矛盾的情况；

步骤S432，将元数据中的每个服务器对应使用的原始的目录中反安装配置项的对应配置项的编号删除，以去掉不必要的配置项,保持配置项无相互矛盾的情况,例如，原来元数据中的配置项的编号为(2，–1)，其中，–1为反安装配置项的对应配置项的编号，则删除后的元数据中的配置项的编号修改为(2)，步骤S431至步骤S432是在全部灰度任务完成后进行。

如图9所示，本申请的一种灰度发布的方法一优选的实施例中，步骤S3执行的同时，还包括步骤S31，对修改原始的目录中的配置项的新的和/或旧的灰度发布任务进行回退，具体包括：

步骤S311，暂停向服务器发送元数据；

步骤S312，修改元数据至不包含待回退的灰度发布任务的状态后，将修改后的元数据向对应服务器发送；在多任务同时进行灰度发布时,若收到请求需要对某一个任务进行回退时,首先暂停元数据的推送,并把所有当前包含回退任务的元数据回退到上一无该待回退的灰度发布任务的状态，以前述修改配置项的四个任务同时进行修改的案例为例,当前同时进行的分发任务有A、B、C、D,现需要对A任务进行回退,那么首先会暂停推送,避免影响进一步扩大,同时修改元数据,即对已包含A的中间environment的元数据进行回退,并提高回退任务的优化级,即把当前为GAY A的元数据回退到BASE,GAY A,B回退到GAY B,GAY A,C回退到GAY C,GAY A,D,回退到GAY D,GAY A,B,C 回退到GAY B,C…以此类推，由于前述步骤S411中已经备份原始的目录和所有新的目录后删除该原始的目录和所有新的目录，即已经备份了所有中间状态环境即原始的目录和所有新的目录,所以这里有回退要求时,可以快速恢复元数据至不包含待回退的灰度发布任务的状态；

步骤S313，若某个服务器根据原先接收到的所述元数据已经完成配置，则该服务器根据接收到的修改后的元数据完成回退配置。在此，可以根据在配置项中设置的标志位来判断某个服务器是否已经完成配置，若是，则需要根据接收到的修改后的元数据进行回退配置，若否，则不需要进行回退配置。

如图10所示，本申请的一种灰度发布的方法一优选的实施例中，步骤S3执行的同时，还包括步骤S32，对新增原始的目录中的配置项的新的和/或旧的灰度发布任务进行回退，具体包括：

步骤S321，暂停向服务器发送元数据；

步骤S322，在原始的目录中添加一个对应于原先新增的配置项的反安装配置项，所述反安装配置项用于删除该目录中对应的原先新增的配置项；

步骤S323，修改元数据并向对应服务器发送，修改后的元数据包括服务器地址、该服务器使用的原始的目录和该原始的目录中替换原先新增的配置编号(即待删除的配置项号)的反安装配置项的编号；

步骤S324，若某个服务器根据原先接收到的所述元数据已经完成配置，则该服务器根据接收到的修改后的元数据完成回退配置。在此，对于新增配置项的回退对应的是删除配置项，可以根据在配置项中设置的标志位来判断某个服务器是否已经完成配置，若是，则需要根据接收到的修改后的元数据进行回退配置，若否，则不需要进行回退配置。

本申请的一种灰度发布的方法一优选的实施例中，步骤S324之后，还包括：

备份原始的目录中的原先新增的配置项和对应的反安装配置项后，删除该原先新增的配置项和对应的反安装配置项，删除元数据中的反安装配置项的编号，以方便后续随时可以回退或者重新执行灰度发布任务的需要。

如图11所示，本申请的一种灰度发布的方法一较佳的实施例中，步骤S3执行的同时，还包括步骤S33，对删除原始的目录中的配置项的新的和/或旧的灰度发布任务进行回退，具体包括：

步骤S331，暂停向服务器发送元数据；

步骤S332，在原始的目录中添加一个对应于原先的反安装配置项的新增的配置项；在此，若该新增的配置项已经存在原始的目录中，则不需要添加；

步骤S333，修改元数据并向对应服务器发送，修改后的元数据包括服务器地址、该服务器使用的原始的目录和该原始的目录中替换原先的反安装配置项的编号(即待删除的配置项的编号)的新增的配置项的编号；

步骤S334，若某个服务器根据原先接收到的所述元数据已经完成配置，则该服务器根据接收到的修改后的元数据完成回退配置。在此，对于删除配置项的回退是重新加入原来的配置项，可以根据在配置项中设置的标志位来判断某个服务器是否已经完成配置，若是，则需要根据接收到的修改后的元数据进行回退配置，若否，则不需要进行回退配置。

本申请的一种灰度发布的方法一优选的实施例中，步骤S334之后，还包括:

删除原始的目录中的所述原先的反安装配置项，以保持最终状态的目录中配置项无相互矛盾。

另外，对于服务器的下线情况，只要直接删除该服务器的元数据即可，而对新的服务器上线的情况，只要增加该服务器的元数据即可。

如图12所示，根据本申请的另一面还提供一种灰度发布的设备100，包括：

第一装置1，用于将新的灰度发布任务和旧的灰度发布任务的配置项存放于目录中，其中，所述新的灰度发布任务和旧的灰度发布任务经冲突检查 合格；在此，所述旧的和新的灰度发布任务是在时间上相对而言的灰度发布任务，如产生时间上较新的则为新的灰度发布任务，如产生时间上较旧的则为旧的灰度发布任务，在一个时刻上的新的灰度发布，如果下一时刻有更新的灰度发布任务，则原来新的灰度发布任务在该时刻则成为了旧的灰度发布任务，另外，所述新的灰度发布任务和旧的灰度发布任务经冲突检查合格，从而保证后续并行执行的灰度发布任务和旧的灰度发布任务发生冲突，若同时有多个新的灰度发布任务产生，则新的灰度发布任务之间也需要经冲突检查合格，新的灰度发布任务可以是对原始的目录的改动，如对原始的目录(BASE)中的配置项进行修改、增加和删除；

第二装置2，用于根据目录及其配置项生成新的和旧的灰度发布任务的所有候选的任务执行路径，，即对新的灰度发布任务和旧的灰度发布任务的进行任意排列组合生成所有候选的任务执行路径，其中，每个旧的灰度发布任务或新的灰度发布任务的执行完成是通过其目录中的配置项对服务器进行配置，每个任务执行路径用于执行旧的灰度发布任务和/或新的灰度发布任务；

第三装置，用于根据每个服务器的灰度发布任务的执行进度和每个灰度发布任务的分发批次，从所有候选的任务执行路径中选择最优的任务执行路径作为修改后的元数据向对应服务器发送，其中，所述元数据包括服务器地址、该服务器对应使用的目录(environment)和相应的配置项(state)的编号，一个配置项的编号与一个配置项对应。具体的，比如现在有10000台数据库服务器需要更新某个配置项A,为确保线上稳定需要将分发批次分为10批进行灰度发布,每一批1000台，开始对应的生成灰度发布任务1，假设现在已推送完5批,并且其中4批灰度发布任务1的服务机机主(owner)已确认通过,第5批还在确认中,这时接到第二个分发任务,需要升级10000台数据库服务器的某个软件包B,通过检查配置文件A和软件B无冲突后,生成灰度发布任务2,同样分发批次分10批进行灰度发布,可以根据旧的灰度发布任务(任务1)的执行进度(旧的灰度发布任务1可能在有些服务器上 已经执行，也有可能未执行)和每个灰度发布任务1、2的分发批次为每个服务器选择对应任务执行路径，如部分服务器已经执行任务1的则再执行任务2，同时，部分服务器还未执行任务1的，将任务1和任务2同时执行，或者考虑到分发批次的问题，部分服务器先执行作任务2再执行任务1，或者先执行任务1再执行任务2，从而实现任务1和任务2可以在不同时的服务器上同时进行执行,并且如果任务1需要回退,由于各任务之间通过冲突检查合格，回退时，也不会影响任务2的继续执行。以此类推,如果再接收到任务3,任务4…任务N都可以同时执行,相互不影响，不冲突。又如，有10000台服务器,A任务要求对这10000台服务器的分发批次为分5批执行,每批执行2000台服务器,然后，又有B任务要求对同样这10000台服务器的分发批次为分20批执行,每次只执行500台服务器，此时，若有有gay A(只执行任务A),gay B(只执行任务B),gay AB(同时执行任务AB)三个候选的任务执行路径,A任务2000台一批,B任务500台一批,那么如果从里面选出2000台从没执行过这两个任务的机器,那按最优化的任务执行路径,那就会有1500台走到gay A,有500台走到gay AB。在此，可通过使用如saltstack的配置管理工具中通用的目录(environment)和配置项(state),所述元数据可以存放于一个文件中,也可以存放于数据库里的一张或者多张表中，例如可以配合使用MySQL数据库存放服务器的元数据,达到多个任务执行路径可以同时并发进行灰度发布的效果，即在一个或者多个灰度发布任务执行中时,可再加入新的灰度发布请求，按分发批次选择最优的任务执行路径,同时保证任务与任务之间相互不干扰，大大加快了分发配置的速度。本实施例的核心思想是在有多个灰度发布任务需求时,通过生成所有可能的任务执行路径即中间目录,然后针对当前不同服务器的状态即灰度发布任务的执行进度和分发批次从中间目录中选择最优的一步任务执行路径作为元数据向对应服务器发送,从而最大限度地实现多任务同时灰度发布。本实施例的核心思想是在有多个灰度发布任务需求时,通过生成所有可能的任务执行路径即中间 目录,然后针对当前不同服务器的状态即灰度发布任务的执行进度和分发批次从所有可能的任务执行路径选择最优的一步任务执行路径作为元数据对应服务器发送,从而最大限度地实现多任务同时灰度发布。

如图13所示，本申请的一种灰度发布的设备一优选的实施例中，所述设备100还包括：

第四装置4，用于在所述第三装置3执行之后，即在从所有候选的任务执行路径中选择最优的任务执行路径作为修改后的元数据向对应服务器发送之后，控制每个服务器根据其接收到的所述元数据完成配置。

本申请的一种灰度发布的设备一优选的实施例中，当新的和旧的灰度发布任务是修改原始的目录(environment中的BASE)中的配置项时，

所述第一装置1，用于每有一个新的灰度发布任务，则复制一个原始的目录(BASE)作为新的目录(GAY A、GAY B、GAY C……)，根据每个灰度发布任务对相应新的目录中的待修改配置项进行修改，得到修改后的配置项；在此，把最原始状态的目录(environment)称为BASE(a b c),当接收到新的灰度发布任务gay A(a'b c)时，即对目录中的a配置项进行修改，则会先从原来的BASE(a b c)复制生成一个新的environmentg为gay A(a b c)，并把gay A里面的配置项a按最新的要求去修改生成gay A(a'b c)，新的灰度发布任务gay A(a'b c)执行时,若接收到另一个新的灰度发布任务gay B(a b'c)要求修改配置项b,这时又会在原来的BASE(a b c)基础上再生成一个新的environment为gay B(a b'c)；

相应的，所述第二装置，根据目录及基配置项对新的灰度发布任务和旧的灰度发布任务的进行任意排列组合生成所有可能的任务执行路径(分发目录)中，如图3所示，若原来的分发目录为(BASE(1 2 3))，在增加新的灰度发布任务gay A时，分发目录修改为(BASE(1 2 3),gay A(1'2 3))，同理，当又接收到新的灰度发布 任务时gay B时，如图4所示，分发目录修改为(BASE(1 2 3),gay A(1'2 3),gay B(1 2'3),gay AB(1'2'3))，三个任务同时灰度发布的分发目录如图5所示，四个任务同时灰度发布的分发目录如图6所示，依此类推，通过复制BASE目录以及生成对不同任务组合过的中间状态environment即所有候选的任务执行路径,并在加入新分发任务时对执行路径进行修改即生成新的所有候选的任务执行路径,最终达到所有任务一致的状态,完成所有分发任务的灰度发布,即使同时进行更多的任务灰度发布,通过本实施例都可以完成.当然,随着同时执行的任务越多,中间environment(gay A，gay B…)的生成会越多,执行路径会更加复杂；

相应的，所述第三装置3向对应服务器发送的元数据包括服务器地址、该服务器对应使用的新的目录和该新的目录中相应的修改后的配置项的编号。在此，新的目录是相对于原始的目录来说的，每产生一个新的修改原始的目录的配置灰度发而任务，则对应会生成一个新的目录，各新的目录的产生在时间上可能有先后关系，但各新的目录之间不存在新旧关系的概念，其可能是新的灰度发布任务的新的目录，也可能是旧的灰度发布任务的新的目录，但各新的目录相对原始的目录来说都是的新的目录。例如，接收到gay A前原来的元数据为machine X-->BASE-->【1】,【2】,【3】，在接收到gay A后，元数据修改为machine X-->gay A-->【1】,【2】,【3】，同理，当又接收到新的灰度发布任务时gay B时，已经执行完gay A的服务器还需要进行分发任务gay B,尚未执行任何任务的机器需要按批次进行gay AB发布，例如，可将未执行gay A的服务器X的元数据又进一步由machine X-->gay A-->【1】,【2】,【3】修改为machine X-->gay AB-->【1】,【2】,【3】，同时，考虑到批次的问题，同时将服务器Y的元数据由原来的元数据machine Y-->BASE-->【1】,【2】,【3】修改为 machine Y-->gay a/gay b/gay AB-->【1】,【2】,【3】，即m achine Y-->gay A--gay AB-->【1】,【2】,【3】，或者machine Y-->gay B--gay AB-->【1】,【2】,【3】，或者machine Y-->gay AB-->【1】,【2】,【3】。

如图14所示，本申请的一种灰度发布的设备一较佳的实施例中，所述设备还包括第五装置5，用于在所述第四装置4执行之后即每个服务器根据接收到的所述元数据完成配置之后，

备份原始的目录和所有新的目录后删除该原始的目录和所有新的目录；在此，需要备份所有中间状态环境即原始的目录和所有新的目录,以防有回退要求时,可以快速恢复目录，备份后即可以删除,避免有多个环境存在而且产生干扰；

以所有新的目录的合并作为新的原始的目录；在此，需要复制最终状态的目录作为原始的目录(BASE),以方便复位,为下一次灰度发布任务准备相对干净无干扰的环境，例如，第一个灰度发布任务gay A(a'b c)是修改配置项a，第二个灰度发布任务gay A(a b'c)是修改配置项b，第一个灰度发布任务gay A(a b c')是修改配置项c，则所有新的目录的合并为gay A(a'b'c')；

修改元数据，所述元数据包括服务器地址、该服务器对应使用的新的原始的目录和该新的原始的目录中相应的修改后的配置项的编号。

如图15所示，本申请的一种灰度发布的设备一优选的实施例中，所述设备100还包括第六装置6，用于在所述第三装置3执行的同时，对修改原始的目录中的配置项的新的和/或旧的灰度发布任务进行回退，具体包括：

暂停向服务器发送元数据；

修改元数据至不包含待回退的灰度发布任务的状态后，将修改后的元数据向对应服务器发送；在多任务同时进行灰度发布时,若收到请求需要对某一个任务进行回退时,首先暂停元数据的推送,并把所有当前包含回退任务 的元数据回退到上一无该待回退的灰度发布任务的状态，以前述修改配置项的四个任务同时进行修改的案例为例,当前同时进行的分发任务有A、B、C、D,现需要对A任务进行回退,那么首先会暂停推送,避免影响进一步扩大,同时修改元数据,即对已包含A的中间environment的元数据进行回退,并提高回退任务的优化级,即把当前为GAY A的元数据回退到BASE,GAY A,B回退到GAY B,GAY A,C回退到GAY C,GAY A,D,回退到GAY D,GAY A,B,C回退到GAY B,C…以此类推，由于前述第五装置5，中已经备份原始的目录和所有新的目录后删除该原始的目录和所有新的目录，即已经备份了所有中间状态环境即原始的目录和所有新的目录,所以这里有回退要求时,可以快速恢复元数据至不包含待回退的灰度发布任务的状态；

若某个服务器根据原先接收到的所述元数据已经完成配置，则该服务器根据接收到的修改后的元数据完成回退配置。在此，可以根据在配置项中设置的标志位来判断某个服务器是否已经完成配置，若是，则需要根据接收到的修改后的元数据进行回退配置，若否，则不需要进行回退配置。

本申请的一种灰度发布的设备一优选的实施例中，当新的和旧的灰度发布任务是增加原始的目录中的配置项时，

所述第一装置1，用于每有一个新的旧的灰度发布任务，则根据每个灰度发布任务将待增加的配置项加入所述原始的目录中；在此，当灰度发布任务是在原始的目录中新增配置项时,并不需要像前述实施例中通过复制BASE来完成,因为增加配置项不会引起目录中的已有配置项的修改，所以只需要在原BASE中直接加入一个新配置项；

相应的，所述第三装置3向对应服务器发送的元数据包括服务器地址、该服务器使用的原始的目录和该原始的目录中相应的待增加配置项的编号。在此，修改元数据中的配置项(state)内容,即加上新的state再进行推送即可，例如若BASE(1 2 3)时，对应的元数据为machine X(服务器X)-->BASE-->【1】,【2】,【3】，当要在BASE时增加的配置项A 时，步骤S121中将BASE改为BASE(1 2 3A)，然后，步骤S321中，对应将元数据修改为元数据machine X-->BASE-->【1】,【2】,【3】,【A】，这里【1】,【2】,【3】,【A】分别为对应于配置项1 2 3 A的配置项的编号，如果同时存在多个新增配置项任务,也是使用同样的方法生成元数据，例如，有两个配置项A和B要增加，根据批次和每个服务器执行进度，可同时增加A和B元数据，也可分步增加A或B的元数据，然后将元数据进行向服务器的推送。

如图16所示，如图本申请的一种灰度发布的设备一较佳的实施例中，所述设备100还包括第七装置7，用于在所述第一装置1执行之前，即在每有一个新的旧的灰度发布任务，则根据每个灰度发布任务将待增加的配置项加入所述原始的目录中之前，备份原始的目录。在此，在新增配置项之前备份当前的BASE环境,是为了后续需要回退的情况发生时，能够顺利地回退到的新增前的BASE环境。

如图17所示，如图本申请的一种灰度发布的设备一较佳的实施例中，所述设备100还包括第八装置8，用于在所述第三装置3执行的同时，对新增原始的目录中的配置项的新的和/或旧的灰度发布任务进行回退，具体包括：

暂停向服务器发送元数据；

在原始的目录中添加一个对应于原先新增的配置项的反安装配置项，所述反安装配置项用于删除该目录中对应的原先新增的配置项；

修改元数据并向对应服务器发送，修改后的元数据包括服务器地址、该服务器使用的原始的目录和该原始的目录中替换原先新增的配置编号(即待删除的配置项号)的反安装配置项的编号；

若某个服务器根据原先接收到的所述元数据已经完成配置，则该服务器根据接收到的修改后的元数据完成回退配置。在此，对于新增配置项的回退对应的是删除配置项，可以根据在配置项中设置的标志位来判断某个服务器是否已经完成配置，若是，则需要根据接收到的修改后的元数据进行回退配 置，若否，则不需要进行回退配置。

如图18所示，如图本申请的一种灰度发布的设备一较佳的实施例中，所述设备100还包括第九装置9，用于在所述第八装置8执行之后，即服务器根据接收到的修改后的元数据完成回退配置之后，备份原始的目录中的原先新增的配置项和对应的反安装配置项后，删除该原先新增的配置项和对应的反安装配置项，删除元数据中的反安装配置项的编号，以方便后续随时可以回退或者重新执行灰度发布任务的需要。

如图本申请的一种灰度发布的设备一较佳的实施例中，当新的和旧的灰度发布任务是删除原始的目录中的配置项时，

所述第一装置1，用于每有一个新旧的灰度发布任务，则根据每个灰度发布任务在原始的目录中分别对应增加一个反安装配置项，所述反安装配置项用于删除该目录中对应的待删除的配置项；

相应的，所述第三装置3向对应服务器发送的元数据包括服务器地址、该服务器使用的原始的目录和该原始的目录中替换待删除的配置项的编号的反安装配置项的编号。在此，该原始的目录中替换待删除的配置项的编号的反安装配置项的编号即，在元数据中的每个服务器使用的原始的目录中去除所述待删除的配置项的对应配置项的编号，并添加所述反安装配置项的对应配置项的编号。这里配置项的删除同样是对BASE中state信息进行修改,但不是直接删除,而是在中间状态新建一个反安装配置项(uninstall state),并在推送元数据前将在原来的元数据中去掉需要删除的state,加入uninstall state。

如图19所示，本申请的一种灰度发布的设备一较佳的实施例中，所述设备还包括第十装置10，用于在所述第一装置1执行之前，即在每有一个新旧的灰度发布任务，则根据每个灰度发布任务在原始的目录中分别对应增加一个反安装配置项的之前，备份原始的目录。在此，在删除配置项之前备份当前的BASE环境,是为了后续需要回退的情况发生时，能够顺利地回退到的新 增前的BASE环境。

如图20所示，如图本申请的一种灰度发布的设备一较佳的实施例中，所述设备100还包括第十一装置11，用于在所述第四装置4执行之后，即在每个服务器根据接收到的所述元数据完成配置之后，备份原始的目录中的待删除的配置项和对应的反安装配置项后，将待删除的配置项和对应反安装配置项从原始的目录中删除，在此，备份原始的目录中的待删除的配置项和对应反安装配置项是为了后续可能回退的需要，将待删除的配置项和对应反安装配置项从原始的目录中删除是为了保持最终状态的目录中配置项无相互矛盾的情况；以及将元数据中的每个服务器对应使用的原始的目录中反安装配置项的对应配置项的编号删除，以去掉不必要的配置项,保持配置项无相互矛盾的情况,例如，原来元数据中的配置项的编号为(2，–1)，其中，–1为反安装配置项的对应配置项的编号，则删除后的元数据中的配置项的编号修改为(2)，

如图21所示，如图本申请的一种灰度发布的设备一较佳的实施例中，所述设备100还包括第十二装置12，用于在所述第三装置3执行的同时，

暂停向服务器发送元数据；

在原始的目录中添加一个对应于原先的反安装配置项的新增的配置项；在此，若该新增的配置项已经存在原始的目录中，则不需要添加；

修改元数据并向对应服务器发送，修改后的元数据包括服务器地址、该服务器使用的原始的目录和该原始的目录中替换原先的反安装配置项的编号(即待删除的配置项的编号)的新增的配置项的编号；

若某个服务器根据原先接收到的所述元数据已经完成配置，则该服务器根据接收到的修改后的元数据完成回退配置。在此，对于删除配置项的回退是重新加入原来的配置项，可以根据在配置项中设置的标志位来判断某个服务器是否已经完成配置，若是，则需要根据接收到的修改后的元数据进行回退配置，若否，则不需要进行回退配置。

如图22所示，如图本申请的一种灰度发布的设备一较佳的实施例中，所述设备100还包括第十三装置13，用于在所述第十二装置12执行之后，即在服务器根据接收到的修改后的元数据完成回退配置之后，删除所述原始的目录中的原先的反安装配置项，以保持最终状态的目录中配置项无相互矛盾。

综上所述，本申请根据每个服务器的灰度发布任务的执行进度和每个灰度发布任务的分发批次，从所有候选的任务执行路径中选择最优的任务执行路径作为修改后的元数据向对应服务器发送，达到多个任务执行路径可以同时并发进行灰度发布的效果，即在一个或者多个灰度发布任务执行中时,可再加入新的灰度发布请求，按分发批次选择最优的任务执行路径,同时保证任务与任务之间相互不干扰，大大加快了分发配置的速度。

进一步的，当新的和旧的灰度发布任务是修改原始的目录中的配置项时，每有一个新的灰度发布任务，则复制一个原始的目录作为新的目录，根据每个灰度发布任务对相应新的目录中的待修改配置项进行修改，得到修改后的配置项，所述元数据包括服务器地址、该服务器对应使用的新的目录和该新的目录中相应的修改后的配置项的编号，实现多个修改原始的目录中的配置项的灰度发布任务能够同时进行。

进一步的，当新的和旧的灰度发布任务是修改原始的目录中的配置项时，通过备份原始的目录和所有新的目录以防有回退要求时,可以快速恢复目录，及备份后删除该原始的目录和所有新的目录，避免有多个环境存在而且产生干扰；通过以所有新的目录的合并作为新的原始的目录，以方便复位,为下一次灰度发布任务准备相对干净无干扰的环境。

进一步的，新的和旧的灰度发布任务是增加原始的目录中的配置项时，通过每有一个新的旧的灰度发布任务，则根据每个灰度发布任务将待增加的配置项加入所述原始的目录中，所述元数据包括服务器地址、该服务器使用的原始的目录和该原始的目录中相应的待增加配置项的编号，实现多个增加原始的目录中的配置项的灰度发布任务能够同时进行。

进一步的，通过在将待增加的配置项加入所述原始的目录中的步骤之前，备份原始的目录，以便后续需要回退的情况发生时，能够顺利地回退到的新增前的BASE环境。

进一步的，新的和旧的灰度发布任务是删除原始的目录中的配置项时，通过每有一个新旧的灰度发布任务，则根据每个灰度发布任务在原始的目录中分别对应增加一个反安装配置项，所述反安装配置项用于删除该目录中对应的待删除的配置项，所述元数据包括服务器地址、该服务器使用的原始的目录和该原始的目录中替换待删除的配置项的编号的反安装配置项的编号，实现多个删除原始的目录中的配置项的灰度发布任务能够同时进行。

进一步的，通过在在原始的目录中分别对应增加一个反安装配置项之前，备份原始的目录，以便后续需要回退的情况发生时，能够顺利地回退到的新增前的BASE环境；通过在每个服务器根据接收到的所述元数据完成配置的步骤之后，备份原始的目录中的待删除的配置项和对应的反安装配置项，以便后续可能回退的需要，然后将待删除的配置项和对应反安装配置项从原始的目录中删除，将元数据中的每个服务器对应使用的原始的目录中反安装配置项的对应配置项的编号删除，以去掉不必要的配置项,保持最终状态的目录中配置项无相互矛盾的情况。

进一步的，通过在从所有候选的任务执行路径中选择最优的任务执行路径作为修改后的元数据向对应服务器发送的同时，对修改、增加、删除原始的目录中的配置项的新的和/或旧的灰度发布任务进行回退，实现即使灰度发布任务执行错误，可以进行快速准确的回退。

显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。

需要注意的是，本申请可在软件和/或软件与硬件的组合体中被实施，例如，可采用专用集成电路(ASIC)、通用目的计算机或任何其他类似硬 件设备来实现。在一个实施例中，本申请的软件程序可以通过处理器执行以实现上文所述步骤或功能。同样地，本申请的软件程序(包括相关的数据结构)可以被存储到计算机可读记录介质中，例如，RAM存储器，磁或光驱动器或软磁盘及类似设备。另外，本申请的一些步骤或功能可采用硬件来实现，例如，作为与处理器配合从而执行各个步骤或功能的电路。

另外，本申请的一部分可被应用为计算机程序产品，例如计算机程序指令，当其被计算机执行时，通过该计算机的操作，可以调用或提供根据本申请的方法和/或技术方案。而调用本申请的方法的程序指令，可能被存储在固定的或可移动的记录介质中，和/或通过广播或其他信号承载媒体中的数据流而被传输，和/或被存储在根据所述程序指令运行的计算机设备的工作存储器中。在此，根据本申请的一个实施例包括一个装置，该装置包括用于存储计算机程序指令的存储器和用于执行程序指令的处理器，其中，当该计算机程序指令被该处理器执行时，触发该装置运行基于前述根据本申请的多个实施例的方法和/或技术方案。

对于本领域技术人员而言，显然本申请不限于上述示范性实施例的细节，而且在不背离本申请的精神或基本特征的情况下，能够以其他的具体形式实现本申请。因此，无论从哪一点来看，均应将实施例看作是示范性的，而且是非限制性的，本申请的范围由所附权利要求而不是上述说明限定，因此旨在将落在权利要求的等同要件的含义和范围内的所有变化涵括在本申请内。不应将权利要求中的任何附图标记视为限制所涉及的权利要求。此外，显然“包括”一词不排除其他单元或步骤，单数不排除复数。装置权利要求中陈述的多个单元或装置也可以由一个单元或装置通过软件或者硬件来实现。第一，第二等词语用来表示名称，而并不表示任何特定的顺序。