一种基于Git的配置生成方法与流程

文档序号:26101563发布日期:2021-07-30 18:12阅读:81来源:国知局
一种基于Git的配置生成方法与流程

本发明涉及一种基于git的配置生成方法,适用于软件微服务相关应用的yaml配置从开发环境到测试或生产环境的生成及发布。



背景技术:

当前流行的微服务,将单体应用中的业务拆分成一个个子服务,每个服务的粒度相对较小,因此系统中会出现大量的服务。由于每个服务都需要必要的配置信息才能运行,另一方面随着产品功能的迭代,服务所需的配置越来越多。所以一套集中式的配置管理设施是必不可少的,这便是配置中心。

项目研发阶段从开发,经历测试再到上线,涉及到dev,sit,prod等多套环境,当进入测试或上线发布阶段,相应环境的配置变更不可避免。

说到配置,应用最多的当属yaml,yaml为纯文本,可读性好,易于移植,使用较为普遍。但由于其层级关系使用缩进空白字符方式,手写极易出错(多一个空格、少一个空格都可能造成配置失效);加之配置的增量变化在项目迭代中不可避免,测试及生产环境的配置更新极为不便。

传统的方式是开发人员对开发环境的配置变更进行整理并通知测试人员,由测试去保证测试及生产环境的配置准确性。项目流程相对规范,但实际操作中配置错误引发的问题频频出现。我们发现:

1.由于开发人员较多,开发侧整理的配置变更说明经常会有遗漏;

2.测试人员根据开发提供的信息所编写出来的配置偶尔会出现书写错误;

3.配置错误带来的问题具有不确定性,往往会浪费很多时间及精力去调研,甚至还可能导致产品上线失败。



技术实现要素:

本发明的目的就是为了解决以上问题,提供一种基于git的配置生成方法,在保留配置中心纯粹的同时,降低配置生成的出错几率,大大提高了开发效率。

为实现上述目的,本发明一种基于git的配置生成方法,包含以下步骤:使用git对配置文件进行版本管理,各个环境配置文件存放在同一git仓库中,假定为repo1,其工作原理如下:1.拉取repo1的最新内容到“latest”目录下;

2.拉取上次发版的内容到“last”目录下;

3.差异对比,对比latest下dev配置与last下dev配置的差异;

4.将变更内容应用到“latest”目录下的sit配置文件中去;

5对于与环境相关的项,可根据实际情况进行手工修改;

6.保存变更,将latest提交到仓库,即完成sit测试环境的配置更新。

优选的,为了得到各配置项的对应节点关系,因此自主实现一种快捷的yaml解析方法,具体方法如下:1-1.逐行读取yaml文件,当下一行开头的空格数量与前一行相等,则为同级节点;

1-2.当开头的空格数量大于前一行,则为前一行配置项的子节点;

1-3.当开头的空格数量,假设为n,小于前一行,则向前查找空格数量小于n的行,此行配置项即是当前行的父节点;

1-4.当遇到注释行,查找下一非注释行,当下一非注释行开头有n个空格,则该注释行开头空格数也重置为n,即注释行父节点与下一数据行父节点相同,多个注释行连续出现时处理方法同样。

为减少时间复杂度,向前查找可替换为另一种算法:

11-1、首先将已经遍历的每行空格数进行字典处理,行首有n个空格,则更新dict[n]=<当前行的行号>,所有行按同样方式进行处理;

11-2.遍历行进到第10行node10,行首有8个空格,查找父节点,只需获取dict[8]的value(数据为行号),从该value指向的行即是node10的同级节点,根据下述差异对比中提到的key(节点名)生成方法,将key的末级名称移除即得到其父节点;

优选的,所述的步骤3中差异对比具体步骤如下:

2-1.将要对比的两个文件基于上述方法分别解析成list,每个节点作为一个item,插入到list末尾,item使用keyvaluepair类型;

2-2.key的产生方法为字符串拼接:<node1><间隔标记><node2>…<间隔标记><noden>,其中noden可以是末节点key,也可以是注释;

noden-1是noden的父节点,noden-2是noden-1的父节点,依次递推;

2-3.value即原配置项的原始内容,检索当前行的第一个“:”,作为有value的依据,当此“:”前出现了“#”,当无value处理;

其中“<间隔标记>”是特殊内容,规避配置中的内容即可,基于此可以准确的逆向生成yaml;

2-4.逐个比较两个list中的keyvaluepair,当key相同则是同名节点,否则匹配不到该节点.比较结果分为:

a.同名节点,value相同;-则两边配置一致,即无变化;

b.同名节点,value不同;-说明配置项有变更;

c.dev的字典中找不到sit的当前key;-dev的此配置项被删除;

d.sit的字典中找不到dev的当前key;dev的此配置项为新增;

优选的,生成yaml配置的方法,因为list中元素为keyvaluepair,key是包含节点关系;

3-1.从key中取到当前item的节点名称,以key“languages<间隔标识>-ruby”为例,其节点名称是“-ruby”;

3-2.统计key中“间隔标记”的数量n;

3-3.写入yaml方法为:

a.生成新的一行,行首空格数=n*2;参照【变更应用】中yaml生成空格计算方法;

b.yaml真正意义上的key是<noden>,以“key”(keyvaluepair的key)“languages<间隔标识>-ruby”为例,其真正的key是“-ruby”

c.当value不为null,写入“:”+空格+<value>;

优选的,所述的步骤4的具体步骤为:

4-1.检索配置项changeitem在latest中dev配置的节点位置;

4-2.当changeitem变更类型为“新增”,则在latest的sit配置文件中创建此内容(查找changeitem在dev与sit的公共前相邻节点nearbyitem1,在sit的nearbyitem1后插入changeitem);

4-3.当changeitem变更类型为“删除”,则在latest的sit配置文件中删除此内容;如果latest的sit中不存在此内容,则无需删除;

4-4.当changeitem变更类型为“更新”,则在latest的sit配置文件中更新相应内容;如果latest的sit配置文件中不存在此内容,则无需更新;

与现有技术相比,本发明的有益效果是:1.该工具方法不会改变配置的原始结构,可以有效的同步并保留注释行;

2.可以美化yaml,对于原始yaml中的注释及数据行行首空格数混乱的情况,生成yaml时会按特定空格数填充行首;

3.操作简便,快捷。

附图说明

图1是本实施例中软件的配置管理界面图;

图2是本实施例配置生成方法流程图。

具体实施方式

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

本实施例提供一种技术方案:参照图1-2所示,一种基于git的配置生成方法包含以下步骤:

1.软件打开时自动获取git库的版本号(tag/commit列表,为方便检索,推荐使用tag号);

2.选择“发布环境”-sit,

3.选择“dev对比版本”;

4.点击“生成配置”,即生成sit环境的配置文件到本地;

5.逐个查看有变更的配置文件。如需要,则进行人工校正;确认无误的配置项需在“confirmed”列打勾。当所有配置项标记为“confirmed”后,文件列表中该文件会显示为绿色-旨在强制对各个变更项进行查看,防止漏看产生漏改的情况。

6.点击“发布配置”,对sit环境的配置进行发布。

其中,自主实现一种快捷的yaml解析方法,得到各配置项的对应节点关系。

1-1.逐行读取yaml文件,当下一行开头的空格数量与前一行相等,则为同级节点;

1-2.当开头的空格数量大于前一行,则为前一行配置项的子节点;

1-3.当开头的空格数量,假设为n,小于前一行,则向前查找空格数量小于n的行,此行配置项即是当前行的父节点;

1-4.当遇到注释行,查找下一非注释行,当下一非注释行开头有n个空格,则该注释行开头空格数也重置为n,即注释行父节点与下一数据行父节点相同,多个注释行连续出现时处理方法同样。

为减少时间复杂度,向前查找可替换为另一种算法:

11-1、首先将已经遍历的每行空格数进行字典处理,行首有n个空格,则更新dict[n]=<当前行的行号>,所有行按同样方式进行处理;

11-2.遍历行进到第10行node10,行首有8个空格,查找父节点,只需获取dict[8]的value(数据为行号),从该value指向的行即是node10的同级节点,根据下述差异对比中提到的key(节点名)生成方法,将key的末级名称移除即得到其父节点。

其中,所述的步骤3中差异对比具体步骤如下:

2-1.将要对比的两个文件基于上述方法分别解析成list,每个节点作为一个item,插入到list末尾,item使用keyvaluepair类型;

2-2.key的产生方法为字符串拼接:<node1><间隔标记><node2>…<间隔标记><noden>,其中noden可以是末节点key,也是注释;

noden-1是noden的父节点,noden-2是noden-1的父节点,依次递推;

2-3.value即原配置项的原始内容,检索当前行的第一个“:”,作为有value的依据,当此“:”前出现了“#”,当无value处理;

以下面片段为例,

得到key-value分别为:

1.key:languages

value:<empty>

2.key:languages<间隔标记>#这是一行注释/说明,“-”表示数组value:<null>

3.key:languages<间隔标记>-ruby

value:<null>

4.key:languages<间隔标记>-perl

value:<null>

5.key:languages<间隔标记>-python

value:<null>

其中“<间隔标记>”是特殊内容,规避配置中的内容即可,基于此可以准确的逆向生成yaml;

示例中“-ruby”是数组类型value之一,但在这里我们并不关心yaml本身的定义,而将其作为key,并无影响-仍然可以逆向写回。

其中<null>与<empty>的区别,<null>表示无value,<empty>表示有值,但内容为空白字符串。

2-4.逐个比较两个list中的keyvaluepair,当key相同则是同名节点,否则匹配不到该节点.比较结果分为:

a.同名节点,value相同;-则两边配置一致,即无变化;

b.同名节点,value不同;-说明配置项有变更;

c.dev的字典中找不到sit的当前key;-dev的此配置项被删除;

d.sit的字典中找不到dev的当前key;dev的此配置项为新增;

其中,生成yaml配置的方法,因为list中元素为keyvaluepair,key是包含节点关系;

3-1.从key中取到当前item的节点名称,以key“languages<间隔标识>-ruby”为例,其节点名称是“-ruby”;

3-2.统计key中“间隔标记”的数量(假设为n);

3-3.写入yaml方法为:

a.生成新的一行,行首空格数=n*2;

b.yaml真正意义上的key是<noden>,以“key”(keyvaluepair的key)“languages<间隔标识>-ruby”为例,其真正的key是“-ruby”

c.当value不为null,写入“:”+空格+<value>,

其中,所述的步骤4的具体步骤为:

4-1.检索配置项changeitem在latest中dev配置的节点位置;

4-2.当changeitem变更类型为“新增”,则在latest的sit配置文件中创建此内容(查找changeitem在dev与sit的公共前相邻节点nearbyitem1,在sit的nearbyitem1后插入changeitem);

4-3.当changeitem变更类型为“删除”,则在latest的sit配置文件中删除此内容;如果latest的sit中不存在此内容,则无需删除;

4-4.当changeitem变更类型为“更新”,则在latest的sit配置文件中更新相应内容;如果latest的sit配置文件中不存在此内容,则无需更新;

说明:公共前相邻节点nearbyitem1指a、b(两个list的当前元素)分别在各自的list中向前找tempitem,tempitem的key一致即为目标。所以该节点可以是a(或b)的同级节点,也可以是其父节点。

本申请所提供的实施例中,应该理解到,所揭露的装置和方法,也可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的,例如,附图中的流程图和框图显示了根据本申请的实施例的装置、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上,流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分,所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意,在有些作为替换的实现方式中,方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如,两个连续的方框实际上可以基本并行地执行,它们有时也可以按相反的顺序执行,这依所涉及的功能而定。也要注意的是,框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合,可以用执行规定的功能或动作的专用的基于硬件的系统来实现,或者可以用专用硬件与计算机指令的组合来实现。

需要说明的是,在本说明书的描述中,参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本发明的至少一个实施例或示例中。在本说明书中,对上述术语的示意性表述不一定指的是相同的实施例或示例。而且,描述的具体特征、结构、材料或者特点可以在任何的一个或多个实施例或示例中以合适的方式结合,本说明书系统实施例,由于其基本相似于方法实施例,所以描述得比较简单,相关之处参见方法实施例的部分说明即可。以上所描述的系统实施例仅仅是示意性的,其中作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元提示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下,即可以理解并实施。

另外,在本申请各个实施例中的各功能模块可以集成在一起形成一个独立的部分,也可以是各个模块单独存在,也可以两个或两个以上模块集成形成一个独立的部分。

所述功能如果以软件功能模块的形式实现并作为独立的产品销售或使用时,可以存储在一个计算机可读取存储介质中。基于这样的理解,本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括当干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括:u盘、移动硬盘、只读存储器(rom,read-onlymemory)、随机存取存储器(ram,randomaccessmemory)、磁碟或者光盘等各种可以存储程序代码的介质。需要说明的是,在本文中,诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来,而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

以上所述仅为本申请的优选实施例而已,并不用于限制本申请,对于本领域的技术人员来说,本申请可以有各种更改和变化。凡在本申请的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本申请的保护范围之内。应注意到:相似的标号和字母在下面的附图中表示类似项,因此,一旦某一项在一个附图中被定义,则在随后的附图中不需要对其进行进一步定义和解释。

以上所述,仅为本申请的具体实施方式,但本申请的保护范围并不局限于此,任何熟悉本技术领域的技术人员在本申请揭露的技术范围内,可轻易想到变化或替换,都应涵盖在本申请的保护范围之内。因此,本申请的保护范围应所述以权利要求的保护范围为准。

当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1