首页 > 其他分享 >超越流水线,企业研发规范落地新思路

超越流水线,企业研发规范落地新思路

时间:2024-08-12 13:27:41浏览次数:8  
标签:落地 流程 新思路 规范 研发 测试 流水线 分支

作者:子丑

内容大纲:

1、研发规范≠流程约束

2、自动化工具→研发规范载体

3、研发规范在工具上的落地示例

4、研发规范的选型方法与常见实践

研发规范≠流程约束

这个故事特别适合研发规范的场景,我们要避免成为把猫绑在柱子上的信众。而要做到这一点,我们先要了解什么是研发规范。

当我们在谈论研发规范时,我们在谈论什么?

有些团队谈起研发规范,会列一个大纲,并制定详尽的规章制度,这些规章制度对他们而言就是研发规范。

这个大纲可能是这样的:

  • 需求管理规范
  • 代码管理规范
  • 制品管理规范
  • 测试管理规范
  • 生产发布规范
  • 安全研发规范

还有些团队会用如下这种图来描述需求从提出到开发到交付的整个过程,准入准出要求、会涉及到哪些人等,他们以此来描述研发规范。

显然,当我们以第 2 种方式描述研发规范的时候,我们能更好地把控研发过程,能够以终为始地去看研发规范。

研发规范的目标、执行挑战

研发规范是跟随软件工程的产生而产生的。随着软件和团队的规模逐渐扩大,软件危机随之产生,为确保软件按时、按质地交付,需要利用软件工程的思路来解决软件危机,由此产生了研发规范。

因此,研发规范的目标是保障软件按时、按质地交付。

要保证软件按时按质地交付,实现研发规范的目标,我们需要从两方面入手,即优化研发团队内外协同机制和提升研发团队工程交付水平。

在制定研发规范时,有两个常见的误区。

一,只关心协作机制,乐衷于制定各种规则。例如,部署前提交发布审批单,其需经过 ABCD 四人的审批及相关人员的签字,审批单里面需要包括 XYZ 项内容等等。

二,只关心工程交付,乐衷于优化单点实践。例如,要求做单元自动化测试,并强调新增代码单元测试覆盖率要达到 100%。

如果只关心协同机制,那么研发规范很快会变成行为约束和规章制度。但是,研发规范还有另外的作用,即通过规范提升团队的工程实践能力。例如代码评审是为了提升大家对整体领域的理解和学习,自动化测试是为了提升快速验证的能力。

如果只关心工程交付,那么研发规范容易陷入一个个具体的实践,而忽视了整个交付流程,导致一眼障目不见泰山。例如测试团队强调测试自动化的实践,但却忽视了当下测试反馈的瓶颈不在测试自动化水平,而在流程中的部署和审批效率低下。

我们的目的应是既解决了协同问题,同时有提升了团队的工程水平。

自动化工具→研发规范载体

确定了研发规范的目标,我们接下来看如何将目标落地。很多时候,在制定研发规范时,我们会编写包含各类规范的详细文档。但仅靠人力去实现这些规范是不现实的。因此,我们会需求工具的帮助,即利用工具去保障文档描述的规范被执行。

但是,文档与工具的执行之间往往存在一定的差距,这个差距该如何去解决呢?

1、案例

上世纪 60 年代,阿波罗八号飞船的事故很好地阐释了这个问题。工程师汉密尔顿在加班时不慎触发了预发射程序,但好在是在测试状态,没有引发事故。这一事件促使汉密尔顿提出在系统中引入错误检查的想法,但负责人认为这种情况不可能发生。后续正如汉密尔顿所担心的,飞船飞行过程中宇航员误触发了这个程序。幸运的是,备份机制起到了关键的作用,避免了更严重的事故发生。

2、启示

仅靠文档定义规范是行不通的,当面临某个问题时,使用者需要按照文档规定的流程将各项任务串联起来解决,且中间不能出错。因此完全依赖使用者处理问题是不可靠的。正如阿波罗八号的例子,如果系统没有备份机制,要求使用者来处理这些问题将会是非常困难的。所以,工具的组合和连接(即如何正确地使用工具完成某个任务),也应该有相应工具来实现,而不是依靠使用者记住这一系列步骤并确保没有任何错误发生。

这个问题的核心是流程的自动化。

流程是工具自动化的过程,人不是流程本身和驱动者,而是参与方之一。只有这样,我们才能保证研发规范符合设计和成功落地。

3、示例:实现按特性的持续交付

通常情况下,研发规范会如何落地?我们利用名为“按特性持续交付”的案例来进行解释。

某企业有 30 左右的研发团队,架构师希望能确保团队的灵活性和快速响应能力。团队应该能够持续交付产品特性,即将产品特性拆解成各应用的开发任务,实现独立部署,以达到灵活性和快速响应业务需求的目的。

基于此,他们的愿景是,每个产品特性可以独立且快速地开发、测试、发布。每个特性对应一个开发分支,这一分支在开发验证和测试验收阶段发挥作用。只有通过开发验证的分支才能进入测试验收,通过测试验收的分支才能进入评审并合入主干,最终进入生产部署。

上面是我们定义的研发规范的概览,在这个概览下我们做了如下几层定义。

  • 产品的交付粒度是一个产品特性,部署力度是一个应用,开发力度是一个 feature 分支。
  • feature 分支必须经过开发、测试,最后到达部署。
  • 在 feature 的整个交付过程中,每个阶段都有准入卡点。比如,如果某个 feature 分支没有经过开发阶段的验证,那么将不能进入测试验收阶段。

4、基于代码库和流水线的解决方案

有了这些规范之后,如果基于代码库和流水线,如何落地呢?

首先,代码库与应用最好一一对应,且代码库会将 master 分支配置为保护分支,其只能被合入,而不能被推送。并且被合入时具有条件限制,其必须通过前面的验证。

其次,我们应该会有两条或三条流水线。此处为开发测试流水线和生产流水线。在开发测试流水线上,开发测试都在这个 feature 分支上。开发测试流水线包含两个部分。第一个部分是开发阶段,它只做了一些构建和单元测试。第二部分是测试阶段,它只做了测试环境的部署以及测试验证。这里,我们是把两个部分是放在 1 条流水线上,即将代码推送到 feature 分支,再进入到单元测试等阶段,如果开发自测通过,确认可以提交测试验证,那么测试可以进入到部署环境阶段,然后进入到测试验证阶段,如果验证通过,则流程结束。

若开发阶段执行频率较高,测试阶段执行频率较低,此时,开发测试可以分为两条流水线。第一条流水线在代码提交后就可触发,但由于第二条流水线是独立存在,存在多种触发条件,无法设置测试必须通过前面的验证。因此,这种情况下会出现测试流水线卡不住的问题。这里为了简单,我们将开发测试合并为一条流水线。

生产流水线比较清晰。当代码合入到 master 分支后,流水线依次经过构建、发布准入和部署到生产环境等阶段。

我们以云效为例对上面的方案做一个演示。

首先,我们在代码库的分支设置中配一个保护分支,它的作用是通过关掉推送,使得任何人不能直接推送到 master 分支上,并且只能通过特定人的权限后才能合入到分支上。此时,可以给合并设置限制条件。例如,将通过代码评审以及通过开发测试流水线作为限制条件。

我们再配置两条流水线。分别为开发测试流水线和生产部署流水线。

开发测试流水线,对应 feature 分支,包含单元测试、源码的漏洞检测、构建、部署测试环境等步骤。同时,也可以按需在其中加入测试准入等步骤。

生产测试流水线,对应 master 分支,包含构建、审核、部署生产环境等步骤。

以上为流水线上的配置,同时在配置时,必须要保证两条流水线上配置的代码源、代码分支和部署环境的正确。

接下来我们看下这个解决方案是否符合前面所定义的研发规范。

我们发现,对于每一个阶段内部的规范,流水线是完全支撑的,但是阶段间的准入很难定义。例如合到 master 之后,需要保证所部署的准入已经通过前面的验证测试,那我们只能通过间接的手段,在保护分支里面设置分支合入的条件,进而达到准入的要求。但是需要注意的是,这两者并不完全对等。另一个问题是,在当前的情况下进行部署时,我们无法知道这次部署所涉及的特性是什么。

5、基于代码库和流水线的解决方案的局限

基于代码和流水线的解决方案,存在两个局限:

一、像早期的 NASA,要正确地执行研发规范,需要配合手册让使用者了解并正确执行操作步骤。包括开始一个新的特性开发时,使用者自行创建一个以 feature- 开头的分支,将代码提交后,使用者需要关注开发测试流水线是否有问题,然后按照要求创建合并请求,把 feature 分支合并到主干。然后,再去检查生产部署流水线是否运行正常。同时,在配置流水线时,使用者需要在执行的层面,保证流水线所对应的环境是正确的。类似宇航员在遇到故障的情况下,他必须遵循手册一步步去执行,如果某一步骤执行有误,那么就可能会出现问题。

二、即使我们根据手册正确地执行研发规定,还是会有信息传递不了,需要依靠线下传递的问题。最典型的就是部署所涉及的特性清单有哪些,而这类清单信息在研发规范中是很常见的。例如当我们作为验收测试的角色,这次测试的范围是什么,测试的东西包含哪些特性和改变,而这些信息需要彼此间传递。但是在传递的中间过程中,信息是否准确完整具有未知性,可能会产生信息丢失,并且后续无法再追溯,除非我们再去另找渠道补充丢失的信息。

6、研发规范承载在哪里?

造成该解决方案的两个局限的根因是什么?在之前,我也问过自己类似的问题,我们制定一个研发规范,它该定在哪里?它的承载是什么?

如果把它按模型的视角画出来,我们就会发现原来的思路明显是有问题的。

按照原来的思路,会发现代码库模板、流水线模板这些研发规范的对象对接不到真实的载体上,这显然是不对的。如果我们参考其他产品或工具的思路,会发现早已有解决方案,只是在工程交付上,没有明确把这个概念提取出来。

很早之前就有了项目的概念,例如云效的项目管理工具 projex,第一步操作往往就是创建项目。项目是研发规范的天然承载体。

进入到工程交付的层面,载体又不太一样。此时项目、代码库已不适合作为载体,因为具体的工作负载、服务、人员在很多时候并不能与代码库和项目一一对应。此外,大库模式或者一个应用涉及到多个代码库。所以在这样的情况下,需要一个名为应用的载体。

以应用承载研发规范在模型上是清晰且合理的。因此,我们引入应用这个概念,并且产生了一个新的产品:云效 AppStack。

应用对应于协作项目或者交付团队、团队空间或产品空间等。相对于项目下的需求,应用下的技术任务被定义为变更请求。

基于云效 AppStack 的研发规范落地演示

我们还是以前面的特性驱动的研发规范来举例。

1、用应用研发流程代替流水线,保证研发规范被正确执行

首先,我们用应用研发流程代替流水线。 因为流水线能定义研发阶段内部的逻辑,无法定义 2 个阶段之间的逻辑。我们引入了一个更上层的概念:研发流程。

简单来说,我们认为研发流程就是 N 条流水线的组合加上流水线的准入限制。

下面,我们进行具体的演示。首先我们会进到 demo-go-echo 这个应用里面。在这个应用里面我们可以看到其研发流程。

在这个研发流程里面,我们可以看到它包含两个阶段,一个测试阶段,一个生产阶段。这与前面两条流水线是可以对应上的。在测试阶段时,我们可以观察到它的触发方式。既可以选择一个 feature 分支去触发,也可以由代码提交自动触发。

接下来,我们看一下研发流程的配置。

如图所示的研发流程里,我们配置了两个阶段,每个阶段为一条流水线,并且阶段间存在准入卡点。例如生产阶段,其分支被固定为 master,并且以测试阶段的成功执行作为准入条件。

此时对照前面的规范,可以发现我们的研发流程与规范所描述的能够完全对应,包括阶段准入、对应分支、环境等。

这样,该研发规范就可完美的映射到 AppStack 的研发流程上,包括成员、角色、研发流程等,都可与规范描述的一一映射。

这样的好处是什么呢?让我们实际走一遍研发流程。

假设我们有个开发任务为实现一个 demo 接口。

我们创建该开发任务,并自动创建 feature 分支,同时因为开发任务的目的是为了满足某个需求,因此我们把这个任务与需求关联起来。

我们修改下代码并提交到该分支,测试阶段会被自动触发,

我们可以清晰地得知,本次触发涉及的特性是什么。同时查看变更详情时,可以看到这个变更对应的需求,点击需求全景图,我们也可展示需求的关联变更,数据都内在地连接了起来。

2、用变更请求贯穿整个应用研发生命周期,保证信息被完整连结

变更请求是一个完整的连接对象,它的作用在于让产品特性的开发任务的各个阶段被聚合起来。在流水线的研发模式里,如果想追溯某一次代码改动,在合入目标分支、打包、测试一路走到哪里,以及当前测的包来源自哪里,当我们想打通双向链路时,里面会存在两个问题。一个问题是,当拿到测试的执行记录时,我们只能拿到分支、来自哪个 commit 的信息,它是合并来的还是代码提交来的等这些问题是未知的。因此,我们在这里做了一个组件来计算这次改动涉及的源头。

这就解决了我们前面的问题:如何收集本次部署所涉及的特性或集成所涉及的特性,即依靠变更请求以及在研发流程中变更管理器的组件来实现。

通过如上的方式,整个应用的研发生命周期都可以连接起来。变更请求有两个目的,一个目的是让开发人员的工程实践被自动同步更新到需求,从而无需手动更新需求的状态;另一个目的是当需要对研发交付进行监控、跟踪和度量时,可以做到端到端的数据连通。

标签:落地,流程,新思路,规范,研发,测试,流水线,分支
From: https://www.cnblogs.com/alisystemsoftware/p/18354772

相关文章

  • 超越流水线,企业研发规范落地新思路
    作者:子丑内容大纲:1、研发规范≠流程约束2、自动化工具→研发规范载体3、研发规范在工具上的落地示例4、研发规范的选型方法与常见实践研发规范≠流程约束这个故事特别适合研发规范的场景,我们要避免成为把猫绑在柱子上的信众。而要做到这一点,我们先要了解什么是研发规范。......
  • 为了给Javaer落地DDD,我们不得不写开源组件
    本文上回书接《这是DDD建模最难的部分(其实很简单)》,欢迎关注我的同名公众号。https://mp.weixin.qq.com/s/HZKMLF0_I10iczzp2mAR-w 故事背景2013年中,我们的Java后端团队为了落地DDD,全面引入了dotnet技术栈,具体过程和成果,可以看我的B站频道《Java8到.NET8,团队升级报告-第......
  • 为了落地DDD,我是这样“PUA”大家的
    本文书接上回《先有鸡还是先有蛋?这是领域驱动设计落地最大的困局》https://mp.weixin.qq.com/s/lzAZXgchCg_VyLmyo2N18Q 故事背景2023年,我加入了一个全新的团队,担任技术Leader的角色,可以算做是“空降”吧,至今已经一年有余的时间了。到目前为止,团队已经完成了领域驱动设计实......
  • 大模型项目落地要注意这五个细节,听懂少走十年弯路
    随着人工智能技术的飞速发展,大模型在各个领域的应用日益广泛。然而,大模型项目落地并非易事,需要面对诸多挑战。本文将为大家提供五个关键策略,帮助你能够将大模型项目顺利落地。一、认清技术边界,寻找合适场景在寻找大模型落地的场景时,首先要了解目前的技术能够做什么,不能做......
  • 【行云流水线】满足你对工作流编排的一切幻想~skr
    流水线模型众所周知,DevOps流水线(DevOpspipeline)的本质是实现自动化工作流程,用于支持软件开发、测试和部署的连续集成、交付和部署(CI/CD)实践。它是DevOps方法论的核心组成部分,旨在加速软件交付、提高质量和实现持续改进。流水线的核心是流水线模型,是实现工作流编排,执行的重要基......
  • [图文直播]Jenkins单分支流水线任务实操
    前言去年的时候,工作角色被定义为去做中台服务,虽然这个工作并不是我职业规划的主线,但正好也借此机会,去解决掉我“闭环能力”中一个暂时缺失的环节,我对自己的定位一直都是要做一个“极限单兵”,希望在地质专业软件这个相对细分的领域,做到自己能完全闭环下面的各个阶段。项目启动->......
  • 开源模型应用落地-LangChain实用小技巧-ChatPromptTemplate的各种花样(三)
    一、前言  在当今的自然语言处理领域,LangChain框架因其强大的功能和灵活性而备受关注。掌握一些实用的小技巧,能够让您在使用LangChain框架时更加得心应手,从而更高效地开发出优质的自然语言处理应用。二、术语2.1.LangChain  是一个全方位的、基于大语言模型这......
  • 精品PPT | 微信云原生大数据平台构建及落地实践.pptx
    一、大数据上云概述1.为什么大数据要上云2.微信大数据平台架构演进二、大数据上云基础建设1.统一编排2.Pod设计及大数据配套能力3.计算组件云环境适配三、稳定性及效率提升1.K8S集群稳定性与弹性配额2.可观测性与智能运维......
  • 智驾功能安全量产落地
    智驾功能安全量产落地不知不觉转到智驾功能安全领域已近3年,笔者也一直在坚持着践行功能安全的量产落地。在最近的项目中,除了定义分配需求、参与设计架构之外,笔者还做了一部分软件开发、单元测试和台架测试的工作,也因此对于功能安全的量产落地有了更深的认识。回望来时的路,......
  • 写作瓶颈怎么破?笔灵AI,突破瓶颈新思路
    在信息爆炸的时代,写作已成为我们日常生活和工作的关键部分。从心得体会、演讲稿到工作总结,再到个人博客和社交媒体内容,优秀的写作是传递信息、表达思想、吸引读者的核心。然而,随着写作需求的增加,如何高效且高质量地完成作品成为挑战。点击立即体验:https://ibiling.cn/template......