基于业务研发的DevOps发布组织管理系统及方法与流程

基于业务研发的devops发布组织管理系统及方法
技术领域
1.本发明涉及基于业务研发的devops发布组织管理系统及方法，属于devops发布组织管理技术领域。


背景技术：

2.devops(development和operations的组合词)是一组过程、方法与系统的统称，用于促进开发(应用程序/软件工程)、技术运营和质量保障(qa)部门之间的沟通、协作与整合。它是一种重视“软件开发人员(dev)”和“it运维技术人员(ops)”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。它的出现是由于软件行业日益清晰地认识到：为了按时交付软件产品和服务，开发和运维工作必须紧密合作。
3.现有的devops发布系统一般基于发布单元着手，描述了发布单元作为应用的最小交付单元，是如何从代码构建开始，到生成版本包，然后送往制品库，最后完成持续交付的。其使用了版本控制系统、相关的构建能力、流水线能力、部署和发布能力等，但在需求层面上，未能实现将研发任务逐一分配到每个开发人员手中，然后每个开发人员围绕每个开发单元是如何组织工作，将各自所作的工作集合起来，合并到发布单元上，最后以需求的方式，将代码的发布单元进行组织并发布。


技术实现要素：

4.本发明的目的在于克服现有技术中的不足，提供基于业务研发的devops发布组织管理系统及方法，能够保障需求研发过程的有序落地，同时保障线上问题排查时，反向追溯变更的原因。
5.为达到上述目的，本发明是采用下述技术方案实现的：
6.第一方面，本发明提供了基于业务研发的devops发布组织管理方法，包括：
7.获取业务需求；
8.将业务需求分解为包含开发子任务的研发需求，其中，所述开发子任务以发布单元维度分解，且每个开发子任务对应唯一一个发布单元；
9.将开发子任务分发至开发人员，以及，为测试人员设置一个与开发子任务相对应的测试子任务；
10.响应于开发人员向开发分支提交对应开发子任务的代码后，触发相关开发子任务的状态流转；
11.将开发人员提交的代码合入发布单中对应发布单元的版本集成分支上，所述发布单由项目经理以版本号的方式组织创建；
12.响应于全部开发子任务开发完成后，基于项目经理的测试指令，将全部开发子任务所对应的发布单元同时部署到指定测试环境中，供测试人员基于测试子任务进行测试；
13.响应于测试结束后，基于项目经理的发布指令发布指定版本的发布单元；
14.正向展现发布单元的树状结构，反向展现发布单元包含的需求改动。
15.进一步的，将业务需求分解为包含开发子任务的研发需求，包括：将业务需求拆分为用户故事的集合后，再将用户故事按照故事涉及的发布单元进行拆解得到开发子任务。
16.进一步的，响应于开发人员向开发分支提交对应开发子任务的代码后，触发相关开发子任务的状态流转，包括：通过获取用户故事的编号和提交人信息，直接触发相关开发子任务的状态流转，其中，所述开发分支根据用户故事的编号自动生成。
17.进一步的，开发人员向开发分支提交对应开发子任务的代码后，所述开发子任务的状态进入“开发中”状态，且任一开发子任务进入“开发中”状态时，则用户故事自动进入“开发中”状态。
18.进一步的，不同的所述研发需求之间相互隔离。
19.进一步的，所述发布单为一系列的发布单元的版本集合，且版本刚创建完毕时发布单为空，在每一个开发子任务完成后，将相对应的发布单元关联到对应版本，同时，相关的开发子任务和发布单内容被填充，建立发布单与开发子任务及需求向的关联关系。
20.进一步的，测试人员基于测试子任务进行测试，包括：发现缺陷时，提交缺陷；缺陷修复后，且对用户故事确认没有遗留问题后，在测试子任务上点击“测试通过”，此时用户故事自动进入“待发布”状态。
21.第二方面，本发明提供了基于业务研发的devops发布组织管理系统，包括：
22.接收模块：用于获取业务需求；
23.分解模块：用于将业务需求分解为包含开发子任务的研发需求，其中，所述开发子任务以发布单元维度分解，且每个开发子任务对应唯一一个发布单元；
24.分发模块：用于将开发子任务分发至开发人员，以及，为测试人员设置一个与开发子任务相对应的测试子任务；
25.状态流转模块：用于响应于开发人员向开发分支提交对应开发子任务的代码后，触发相关开发子任务的状态流转；
26.合入模块：用于将开发人员提交的代码合入发布单中对应发布单元的版本集成分支上，所述发布单由项目经理以版本号的方式组织创建；
27.测试模块：用于响应于全部开发子任务开发完成后，基于项目经理的测试指令，将全部开发子任务所对应的发布单元同时部署到指定测试环境中，供测试人员基于测试子任务进行测试；
28.发布模块：用于响应于测试结束后，基于项目经理的发布指令发布指定版本的发布单元。
29.追溯模块：用于向正向展现发布单元的树状结构，反向展现发布单元包含的需求改动。
30.第三方面，本发明提供了基于业务研发的devops发布组织管理装置，包括处理器及存储介质；
31.所述存储介质用于存储指令；
32.所述处理器用于根据所述指令进行操作以执行根据上述任一项所述方法的步骤。
33.第四方面，本发明提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现上述任一项所述方法的步骤。
34.与现有技术相比，本发明所达到的有益效果：
35.本发明着眼在将研发过程从业务需求开始，先分解到项目团队，再分解到开发个人。而分解到个人的同时，也聚焦在唯一的发布单元上。如此，建立了研发需求与发布单元的一对多映射关系。在提交代码时，将代码与开发任务关联，于是进一步建立了研发需求与代码的一对多映射关系。最终的结果，是无论从正向(需求向代码查看)或者反向(代码向需求查看)，都有清晰地树状结构，能够保障需求研发过程的有序落地，同时保障线上问题排查时，反向追溯变更的原因。
附图说明
36.图1是本发明实施例一提供的业务需求的分解示意图；
37.图2是本发明实施例一提供的开发子任务的处理流程图；
38.图3是本发明实施例一提供的版本刚创建完毕的发布单示意图；
39.图4是本发明实施例一提供的开发子任务的发布示意图；
40.图5是本发明实施例一提供的版本测试通过的发布单示意图；
41.图6是本发明实施例一提供的发布版本示意图。
具体实施方式
42.下面结合附图对本发明作进一步描述。以下实施例仅用于更加清楚地说明本发明的技术方案，而不能以此来限制本发明的保护范围。
43.实施例一：
44.基于业务研发的devops发布组织管理方法，以下方法可基于一个内部的自动化平台进行实际实现，本发明中，将该自动化平台命名为dpmp平台。
45.请参阅图1，业务需求的分解过程：业务需求应当在被确认后，逐步向研发需求分解。其中，研发需求可以根据研发组织的团队情况进行进一步的分解。例如，业务需求req在被业务和研发的需求人员确认后，由架构师进行细分为epic或者story，此时epic或者story作为研发需求进入研发项目团队。在本专利中，业务需求指req，研发需求指epic和story。研发项目团队是负责研发需求交付的唯一责任人，每个研发项目团队对进入自己团队的epic或者story的交付负责。如果自己的epic或者story依赖其他研发团队的，需要在req拆分的过程中明确提出，并在所依赖的项目团队中创建相关的epic’或story’。story(也称为user story或者用户故事)作为最小可独立交付颗粒度的需求进行开发和测试工作。也即，项目团队对单一story的分解要求是可独立测试、可快速交付。epic通常作为一组story的集合，用于在用户故事尚未明晰，或者拆分req时候的集中管理，帮助项目组缩小管理负荷。
46.不同项目团队通常在研发需求范围上进行隔离。即，本项目团队只对自己的研发需求细节可见。对所依赖的其他项目团队研发需求，通常以某个研发需求单号+研发需求名称进行关联跟踪。
47.项目团队的开发核心是story。项目团队将story进一步按照技术框架进行分解到人，使研发工作能够进行。一个故事需要能够按照故事涉及的发布单元进行拆解为开发子任务。此处的发布单元是版本构建、部署和发布的基本单元，是构成一个系统级应用的最小
单元。
48.拆分的原则是：a、一个故事下拆分的开发子任务，必须唯一对应一个发布单元，同时有一个开发人员负责其开发。b、一个开发人员，不能在同一个故事下，拥有对同一发布单元的多个开发子任务。
49.该拆分完毕后，开发人员可以直接根据各自的开发人员进行独立开发，并拥有独立的任务进行进度跟踪。同时，为测试人员拆分一个测试子任务，作为测试人员工作的跟踪项。测试针对整体story，在所有的开发工作结束后进行。
50.请参阅图2，开发人员根据自己的工作，着手进行开发。首先将工作在自己的开发分支上，该分支由dpmp平台根据story的编号自动生成。开发分支用于开发人员仅将该story的代码提交到该分支上。在代码提交的过程中，开发人员在向版本管理系统(例如git)提交时携带story的编号，来描述所提交代码是为了完成哪个story。此时dpmp平台即可以通过该编号和提交人信息(同一故事下发布单元和开发人的唯一性)，直接触发相关开发子任务的状态流转。一旦有代码提交，开发子任务的状态就可以进入“开发中”。同样的，任一开发子任务进入“开发中”状态，则story自动进入“开发中”状态。多个story往往同时进行开发，并且项目团队需要决定在什么时候发布哪些story。此时需要项目团队以版本的方式组织相关的测试和发布动作。项目团队创建版本，版本号通常由项目团队按照一定规则定义。但需要保障版本号的唯一性。项目团队基于版本号进行发布单的组织，发布单为一系列的发布单元的版本集合。请参阅图3，在版本刚创建完毕时，发布单为空。在每一个开发子任务完成后，相对应的发布单元也就完成了。将发布单元关联到对应版本时，相关的任务和发布单内容被即可被填充，且建立起发布单与子任务的关联关系，从而建立起发布单与需求的关联关系。
51.请参阅图4，开发人员小李在完成了自己的开发任务1并自测后，将代码合入到发布单元a的版本集成分支上。此时，版本集成分支的编号与版本的编号具有关联性。该动作表示了该开发子任务所包含的代码变更，计划被本版本发布。合入动作会自动触发该单元的构建，并生成发布单元a的制品版本a-1，此时该版本的发布单下，则增加了发布单元a，其中包含了可选制品a-1。
52.随后，开发人员小王在完成自己开发任务2并自测后，将代码合入发布单元a的版本集成分支上。此时，该版本发布单下，单元a包含的可选制品有a-1和a-2两个。前者只包含开发子任务1的改动，而后者包含了开发子任务1和开发子任务2的改动。dpmp平台可以通过版本管理系统中的提交编号清楚地知道改动情况。
53.项目经理可以选择a-1或者a-2来区分本发布单元a的提测和发布的范围。当然，也可以去掉某个单元，或通过增加story来增加单元(story下的所有或部分开发子任务)。如此，发布单中包含的story的提测范围可以被确定。请参阅图5，发布单元c所对应的开发任务4尚未合入到集成分支并构建，但是项目经理依然可以提前规划该版本所包含的所有story的交付。
54.在合入到发布版本后，小李和小王将开发子任务状态置为“开发完成”状态。当一个故事下，所有开发子任务都进入“开发完成”状态后，项目经理在版本发布单中，把这批开发子任务所对应的发布单元同时部署到某个测试环境，此时story可测。自动化的部署可使用salt或前述发明中的方式。
55.dpmp平台在部署后，将story置为“测试中”状态，测试人员得到该通知后，即将展开测试工作。
56.测试人员在测试，提交缺陷，缺陷修复后，对story确认没有遗留问题后，在测试子任务上点击“测试通过”。则表示story可以发布，因此story自动进入“待发布”状态。
57.请参阅图6，当前版本的所有story都测试通过后，项目经理再次检查版本包含的所有内容，此包含内容的组织方式，是通过story-》开发子任务-》发布单元进行数据关联而呈现的。在发布单中的展现，则是从发布单元出发，反向展现哪些story的开发子任务被本版本包含。
58.项目经理将该版本制品进一步整体部署到生产环境，注意，此时出于某些原因(通常是业务诉求变化或者外部依赖变化)，项目经理并未选择a-2作为需要发布的制品，而仅选择了a-1进行生产部署。在部署完成后，项目团队和业务人员进行生产验证，dpmp平台则按照一定的规则(例如生产部署后24个小时或生产验证后点击按钮确认)来自动完成开发子任务的发布动作，将相应的开发子任务设置为“已发布状态”。
59.此时从发布单元看，实际被发布的版本为a-1、b-1和c-1。从开发子任务来看，开发子任务1、开发子任务3和开发子任务4被发布了。而从研发需求的角度来看，实际被发布的最小可交付story只有story2。story2的状态被自动置为“已发布”状态。
60.进一步的，业务人员查看其业务需求req的时候，则可以通过req的分解关系，了解到该req下拆分的多个story实际的发布情况。当req下所有story都被发布后，则req实际所有功能都已发布上线。
61.同时，从req层面，可以逐层往下追溯，查看所有改动包含的所有代码。所有代码变更都可以汇总展现在开发子任务层。
62.而从开发提交的代码，也能够追溯到开发子任务，从而轻松地追溯到是为了哪个story、哪个业务req所做。
63.实施例二：
64.基于业务研发的devops发布组织管理系统，可实现实施例一所述的基于业务研发的devops发布组织管理方法，包括：
65.接收模块：用于获取业务需求；
66.分解模块：用于将业务需求分解为包含开发子任务的研发需求，其中，所述开发子任务以发布单元维度分解，且每个开发子任务对应唯一一个发布单元；
67.分发模块：用于将开发子任务分发至开发人员，以及，为测试人员设置一个与开发子任务相对应的测试子任务；
68.状态流转模块：用于响应于开发人员向开发分支提交对应开发子任务的代码后，触发相关开发子任务的状态流转；
69.合入模块：用于将开发人员提交的代码合入发布单中对应发布单元的版本集成分支上，所述发布单由项目经理以版本号的方式组织创建；
70.测试模块：用于响应于全部开发子任务开发完成后，基于项目经理的测试指令，将全部开发子任务所对应的发布单元同时部署到指定测试环境中，供测试人员基于测试子任务进行测试；
71.发布模块：用于响应于测试结束后，基于项目经理的发布指令发布指定版本的发
布单元。
72.追溯模块：用于向正向展现发布单元的树状结构，反向展现发布单元包含的需求改动。
73.实施例三：
74.本发明实施例还提供了基于业务研发的devops发布组织管理装置，可实现实施例一所述的基于业务研发的devops发布组织管理方法，包括处理器及存储介质；
75.所述存储介质用于存储指令；
76.所述处理器用于根据所述指令进行操作以执行下述方法的步骤：
77.获取业务需求；
78.将业务需求分解为包含开发子任务的研发需求，其中，所述开发子任务以发布单元维度分解，且每个开发子任务对应唯一一个发布单元；
79.将开发子任务分发至开发人员，以及，为测试人员设置一个与开发子任务相对应的测试子任务；
80.响应于开发人员向开发分支提交对应开发子任务的代码后，触发相关开发子任务的状态流转；
81.将开发人员提交的代码合入发布单中对应发布单元的版本集成分支上，所述发布单由项目经理以版本号的方式组织创建；
82.响应于全部开发子任务开发完成后，基于项目经理的测试指令，将全部开发子任务所对应的发布单元同时部署到指定测试环境中，供测试人员基于测试子任务进行测试；
83.响应于测试结束后，基于项目经理的发布指令发布指定版本的发布单元；
84.正向展现发布单元的树状结构，反向展现发布单元包含的需求改动。
85.实施例四：
86.本发明实施例还提供了一种计算机可读存储介质，可实现实施例一所述的基于业务研发的devops发布组织管理方法，其上存储有计算机程序，该程序被处理器执行时实现下述方法的步骤：
87.获取业务需求；
88.将业务需求分解为包含开发子任务的研发需求，其中，所述开发子任务以发布单元维度分解，且每个开发子任务对应唯一一个发布单元；
89.将开发子任务分发至开发人员，以及，为测试人员设置一个与开发子任务相对应的测试子任务；
90.响应于开发人员向开发分支提交对应开发子任务的代码后，触发相关开发子任务的状态流转；
91.将开发人员提交的代码合入发布单中对应发布单元的版本集成分支上，所述发布单由项目经理以版本号的方式组织创建；
92.响应于全部开发子任务开发完成后，基于项目经理的测试指令，将全部开发子任务所对应的发布单元同时部署到指定测试环境中，供测试人员基于测试子任务进行测试；
93.响应于测试结束后，基于项目经理的发布指令发布指定版本的发布单元；
94.正向展现发布单元的树状结构，反向展现发布单元包含的需求改动。
95.需要说明的是，任何时候，项目经理可以查看当前需求的实际开发状态或者发布
情况，也可以查看某个发布单元所包含的需求改动情况。
96.本领域内的技术人员应明白，本技术的实施例可提供为方法、系统、或计算机程序产品。因此，本技术可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本技术可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。
97.本技术是参照根据本技术实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
98.这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
99.这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
100.以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明技术原理的前提下，还可以做出若干改进和变形，这些改进和变形也应视为本发明的保护范围。