一种多版本并发场景下的数据管理方法及系统与流程

1.本发明涉及代码管理领域，特别涉及一种多版本并发场景下的数据管理方法及系统。


背景技术：

2.基于git的代码数据管理流程最常用的是git flow和github flow，两种类型的管理流程适用于不同的场景；其中github flow 相对来说比较简单，适用串行开发，同时要求开发者的代码质量比较高，而且需要一个专家团队进行整个代码的评审和合并，更适合开源社区，不适合普通的项目开发；git flow 更适合项目开发代码的管理，考虑到了线上bug的解决方案，多版本并行开发的问题，但是对于复杂发布环境下的代码开发会存在一些问题。
3.因此，急需提供一种多版本并发场景下的数据管理方法以解决以下问题：（1）当两个分支的测试阶段基本重合的场景下，特性分支a先合并到开发分支，同时生成发布分支，特性分支b合并到开发分支之后，开发分支会有分支b和分支a两个分支的代码。这个时候生成发布分支就会造成分支b带上了分支a的数据。这个时候如果b是先上线的，那么可能造成a分支的bug也会跟着上线；（2）测试阶段修复bug都是在发布分支上，当修复bug的时候造成了出现严重性的引入bug，影响测试流程的时候如何马上恢复上一个版本；（3）多版本并行开发的时候，会出现代码的冲突，这个流程是发布正式版的时候，统一合并到主分支，这样缺少了多版本联合测试环节，合并代码的时机有些延迟；（4）无法保证最后的代码全部经过测试，会发生漏测试的代码上线的问题。


技术实现要素：

4.为实现上述目的，发明人提供了一种多版本并发场景下的数据管理方法，包括：主分支：用于需求开发从主分支中切出代码；开发分支：测试阶段将功能分支合并到开发分支中，通过开发分支创建测试标签，测试人员发布对应的标签进行测试；功能分支：用于处理开发阶段或测试阶段修复bug。
5.作为本发明的一种优选方式，从需求开发到发布测试版包括以下步骤：需求确认后，从主分支创建功能分支和开发分支；在开发阶段，功能分支提交代码；测试阶段，打测试版tag，并判断主分支是否更新，若是，则合并主分支中的代码到功能分支，然后再合并功能分支的代码到开发分支；若否，则合并功能分支的代码到开发分支；然后，从开发分支创建tagn，创建后删除tagn和n-1之外的测试版tag，并判断是否需要多版本合并，若是，则将多版本合并到一个独立的开发分支后，再发布测试版；若否，则直接
分布测试版。
6.作为本发明的一种优选方式，tag的命名以hotfix_开头，加上版本号，再加上_n，其中n为创建的tag的个数；所述开发分支还用于隔离开发和测试；开发分支的生命周期与产品需求的生命周期相同，产品需求结束，开发分支随之结束。
7.作为本发明的一种优选方式，还包括测试阶段的回滚，所述测试阶段的回滚包括：测试阶段保留两个测试分支，分别为新分支和新分支的上一次分支，新分支的上一次分支用于紧急情况下的回滚。
8.作为本发明的一种优选方式，还包括多版本合并发布，所述多版本合并发布包括：当多个版本在一个测试服务器上同时测试时，增设一个独立分支，在打包测试版标签的时候，将全部需要的开发分支合并到该独立分支上，发布测试版的时候发布该独立分支。
9.作为本发明的一种优选方式，正式版发布包括以下步骤：发布打包后，判断是否为第一次发布；若是第一次发布，则弹出配置检查列表进行配置检查及调整，然后判断是否检查通过，若否则重新配置检查及调整，若是，则判断检查上次发布版本和主分支的版本是否一致，若不一致，则合并版本并重新走测试版，若是，则创建正式版tag，发布正式版；若非第一次发布，则判断检查上次发布版本和主分支的版本是否一致，若不一致，则合并版本并重新走测试版，若是，则创建正式版tag，发布正式版。
10.作为本发明的一种优选方式，在发布正式版之前还包括步骤：从jenkins中获取上次发布的版本和主分支最近一次合并的版本进行对比，若相同说明主分支代码没有问题，若不同则重新走测试版，对上一个版本合并之后进行测试；发布正式版完成之后与合并代码到主分支之间设有时间延迟用于修复错误或进行暂停发布操作，所述发布正式版完成之后与合并代码到主分支是在确认成功上线之后执行。
11.为实现上述目的，发明人还提供了一种多版本并发场景下的数据管理系统，包括，上述发明内容任意一项所述的多版本并发场景下的数据管理系统，还包括使用gitlab和jenkins提供的api实现打包流程和钉钉群通知，实现打包流程和钉钉群通知包括以下步骤：可视化打包流程，展示打包阶段；选择打包应用及版本；通过前端发送ajax请求主动推送信息给钉钉通知群。
12.作为本发明的一种优选方式，所述打包包括正式版打包，所述正式版打包包括版本对比，所述版本对比包括以下步骤：使用jenkins的api获取最新发布的版本与gitlab上最后合并的分支进行对比，若分支相同，则表示最后一次发布的分支已与主分支进行合并，若分支不同，则表示上一次发布的版本没有合并到主分支，则需要做合并操作，然后进行测试之后再做发布。
13.作为本发明的一种优选方式，还包括将该系统嵌入钉钉中，利用钉钉的api进行权限控制，实现打包操作。
14.区别于现有技术，上述技术方案所达到的有益效果有：本方法有效的解决了多版本并发、测试阶段重叠、发布的问题；解决了正式版发布的时候未经测试的代码被发布上线的问题；解决了测试阶段出现异常需要紧急回滚的情况的兼容问题；达到了多版本并行，单一版本发布后，及时合并做联合测试的效果；除此之外，本方法还有效的减少了代码数据管理的复杂度，方便代码数据的打包和发布，简单易操作，解决了多版本并行开发场景下的测试问题，保证发布代码数据的正确性。
附图说明
15.图1为具体实施方式所述git flow的管理流程图。
16.图2为具体实施方式所述github flow的管理流程图。
17.图3为具体实施方式所述分支管理流程图。
18.图4为具体实施方式所述需求开发到发布测试版的流程图。
19.图5为具体实施方式所述正式版发布流程图。
20.图6为具体实施方式所述测试版打包功能界面图。
21.图7为具体实施方式所述正式版打包功能界面图。
22.图8为具体实施方式所述钉钉通知消息界面图。
具体实施方式
23.为详细说明技术方案的技术内容、构造特征、所实现目的及效果，以下结合具体实施例并配合附图详予说明。
24.基于git的代码数据管理流程最常用的是git flow和github flow，git flow和github flow的管理流程如图1和图2所示。其中github flow 相对来说比较简单，适用串行开发，同时要求开发者的代码质量比较高，而且需要一个专家团队进行整个代码的评审和合并，更适合开源社区，不适合普通的项目开发；git flow 更适合项目开发代码的管理，考虑到了线上bug的解决方案，多版本并行开发的问题，但是对于复杂发布环境下的代码开发会存在一些问题。
25.图3为三个分支的管理流程图，其中master为主分支、development为开发分支、feature为功能分支。
26.主分支：所有的需求开发都是从主分支中切出代码，主分支中的代码和正式环境中的代码保持一致。
27.开发分支：测试阶段将功能分支合并到开发分支中，通过开发分支创建测试标签，测试人员发布对应的标签就可以进行测试。正式版发布的标签也是从开发分支中创建的，如图3中的hotfix_tag1实际上是标签名前缀为hotfix来标识这是测试版的标签，其只是一个标识不是分支，tag1代替的就是版本号，发布正式版也是通过标签实现的，只是标签不包含hotfix，直接打出版本号，在本实施例中开发分支和git flow中的开发分支的功能是不同的，主要包括以下两点不同，第一点不同是：开发分支的生命周期和产品需求的生命周期相同，产品需求结束，开发分支跟着结束，不会和主分支一样需要一直维护；第二点不同是：开发分支主要用于隔离开发和测试，没有经过打包过程，功能分支代码不会合并到开发分支。测试和修复测试问题之间会有明确的隔离，可以放心在功能分支上开发代码而不用担
心功能分支上的代码影响到测试。开发分支保证了正式版上线的问题一定是经过测试的，不会出现漏测试的情况。
28.功能分支：用于代码开发过程中使用，开发人员只需要将代码提交到功能分支中，无论是在开发阶段还是测试阶段修复bug统一在一个分支中处理，简化了开发人员管理分支的流程，不需要切换分支。
29.本实施例简化了hotfix和release两个分支，因为release和hotfix本身源于git flow对于需求开发和bug修复的定义，方便区分出此版本是需求开发还是bug修复，但是这两种版本完全可以通过版本号来区分。由于本实施例中的流程是完全重建的流程，所以减除了不需要的分支定义，开发人员只需要知道在功能分支上进行开发即可，唯一不同的就是版本号，没有其他的干扰信息。对于需要区分版本解决什么问题的管理者来说只需要看版本号即可，无需将管理者所需要关注的点强行附加到开发人员身上。在本实施例中，简化了hotfix和release这两个分支，使用版本号来代替，具体的，版本号的最后一位为hotfix使用，前面几位用于需求版本，在本实施例中使用了4位版本号，比如：版本号1.2.3.4，其中：第一位：1代表系统性的优化，方向性版本调整第二位：2 代表正常的需求第三位：3 代表小的优化版本开发第四位：4 代表bug修复版本如图4所示，本实施例为测试版打包流程，即从需求开发到发布测试版的流程，具体包括以下步骤：需求确认后，从主分支创建功能分支和开发分支；在开发阶段，功能分支提交代码；测试阶段，打测试版tag，并判断主分支是否更新，若是，则合并主分支中的代码到功能分支，然后再合并功能分支的代码到开发分支；若否，则合并功能分支的代码到开发分支；然后，从开发分支创建tagn，创建后删除tagn和n-1之外的测试版tag，并判断是否需要多版本合并，若是，则将多版本合并到一个独立的开发分支后，再发布测试版；若否，则直接发布测试版。在本实施例中，先判断主分支是否有新的更新，如果有更新需要合并到功能分支，合并后将功能分支的代码合并到开发分支。主分支合并代码可以及时的更新到上一个版本的代码，第一可以进行联合测试，第二可以防止后续的代码修改引入的冲突，第三防止发布的时候合并代码遗漏。
30.在上述实施例中，从开发分支打出tagn，tag的命名以hotfix_开头，加上版本号，再加上_n，n为打出的tag的个数，比如：hotfix_1.0.0.0_1。
31.在某些实施例中，还包括测试阶段的回滚设计，具体的，在测试阶段保留2个测试分支，其中一个为最新分支（tagn），另一个为最新分支的上一次分支（tagn-1），最新分支的上一次分支（tagn-1）用于紧急情况下的回滚使用。在本实施例中，测试每天都可能多次发布版本，如果恰好有一个版本的修改造成页面访问异常，阻塞了测试进度。排查需要一些时间，这个时候为了不影响测试的进度，可以发布上一个测试tag，从而可以有效的达到：给开发足够的时间调整问题以及防止测试过程被阻塞的效果。
32.在不同的实施例中，还包括多版本合并发布，具体的：在特殊情况下，比如：我们的后台系统是一个多业务的组合系统，涉及到多个项目组同时进行开发，同时测试的情况。当n个版本同时测试，不会准备那么多的测试环境。那么对于特殊的应用，我们增加了一个独
立分支，当需要多个版本在一个测试服务器上同时测试，我们提供了一个功能，在打包测试版标签的时候，将所有需要的开发分支都会合并到这个独立分支上，发布测试版的时候发布这个独立分支即可。
33.如图5所示，本实施例为正式版发布流程，具体的：在发布打包后，判断是否为第一次发布；若是第一次发布，则弹出配置检查列表进行配置检查及调整，然后判断是否检查通过，若否则重新配置检查及调整，若是，则判断检查上次发布版本和主分支的版本是否一致，若不一致，则合并版本并重新走测试版，若是，则创建正式版tag，发布正式版；若非第一次发布，则判断检查上次发布版本和主分支的版本是否一致，若不一致，则合并版本并重新走测试版，若是，则创建正式版tag，发布正式版。
34.发布正式版完成之后与合并代码到主分支之间设有时间延迟用于修复错误或进行暂停发布操作，所述发布正式版完成之后与合并代码到主分支是在确认成功上线之后执行。在本实施例的具体实施过程中，每次正式版发布完成之后不会马上合并代码到主分支，当天上线成功之后才合并到主分支，因为正式版发布后可能会出现问题，修复之后再发布，或者在发布过程中接到紧急通知暂停发布，所以主分支的合并是在确认成功上线之后执行，不会在第一次发布之后执行；暂停发布的场景包括业务临时要求当前需求延期上线待业务做好前期工作的收尾，或者是由于出现重大的逻辑问题导致需求上线会出现重大问题而做的回滚情况。
35.在上述实施例中，由于有一个时间的延迟，所以有可能会出现漏合代码的问题，基于此，在发布正式版之前会再次做一遍检查。具体的包括步骤：从jenkins（集成发布平台）中获取上次发布的版本和主分支最近一次合并的版本进行对比，若相同说明主分支代码没有问题，若不同则重新走测试版，对上一个版本合并之后进行测试。
36.如图6、图7和图8所示，在某些实施例中，还提供了一种多版本并发场景下的数据管理系统，包括，上述实施例任意一项所述的多版本并发场景下的数据管理方法，还包括使用gitlab和jenkins提供的api实现打包流程和钉钉群通知，实现打包流程和钉钉群通知包括以下步骤：可视化打包流程，展示打包阶段；选择打包应用及版本；通过前端发送ajax请求主动推送信息给钉钉通知群。
37.在上述实施例的具体实施过程中，为了方便发布人员使用，内部开发了一套系统，核心是利用了gitlab和jenkins提供的api实现打包流程实现和钉钉群通知功能。钉钉群的通知功能是利用了钉钉自定义机器人接入功能实现的；该系统实现了上述流程，简化了打包的复杂度，只需要对应的应用和版本，一键实现打包流程。
38.图6为测试版打包功能界面图，图7为正式版打包功能界面图。
39.该系统具有以下功能：（1）打包流程进度可视化，头部展示了打包流程到了哪个阶段（如图6和图7所示）；在代码合并过程中可能遇到需要人工干预的代码冲突，知道在哪个环节出现问题，及时定位问题；（2）应用及版本可选，可选择打包何种应用，由于我们的业务比较多，所以工程项目也比较多，每次发布版本的时候需要选择打包何种应用，哪个版本；（3）针对特殊应用，提供了多版本测试功能，可以合并多个版本代码合并；（4）钉钉通知群，可以选择通知哪个业务群，或者不做通知。钉钉通知群主要是用于开发，测试，运营人员的
协同，当分支标签打出来之后，及时的通知到对应的群里，收到群消息的人员直接可以做发布操作，不需要再做线下的沟通；具体的，钉钉通知的实现是通过前端发送ajax请求实现主动推送的，钉钉通知消息如图8所示。在不同的实施例中，对于临时需要发布的需求，可能遇到临时的bug修复等问题，负责打包发布人员如果不在公司，那么就会极其不方便，为了方便处理紧急需求，还可以将该系统嵌入钉钉中，利用钉钉的api进行权限控制，实现打包操作。
40.除此之外，在某些实施例中，针对正式版打包，系统还提供了版本对比功能，具体的：正式版的发布是通过jenkins持续集成工作进行的。jenkins提供了一套api可以获取到最新发布的版本信息。管理平台通过api获取了最新发布的版本对比gitlab上最后合并的分支（通过gitlab提供的api），如果分支相同，则最后一次发布的分支已经合并到了主分支，如果不同说明上一次发布的版本没有合并到主分支，需要做合并操作，然后进行测试之后再做发布。
41.需要说明的是，尽管在本文中已经对上述各实施例进行了描述，但并非因此限制本发明的专利保护范围。因此，基于本发明的创新理念，对本文所述实施例进行的变更和修改，或利用本发明说明书及附图内容所作的等效结构或等效流程变换，直接或间接地将以上技术方案运用在其他相关的技术领域，均包括在本发明的专利保护范围之内。