当前位置: 首页 > Web前端 > HTML

低代码多分支协同开发的构建与实践

时间:2023-03-29 13:05:52 HTML

作者:黄叶(庞丁)简介随着低代码的流行,在低代码平台上构建企业级应用逐渐成为一种生产趋势。同时,随着低代码技术的提升,越来越多的复杂应用在低代码平台上完成。在其研发生命周期中,低代码开发者将面临多人协作、并行开发、多版本维护等场景。然而,现有的低代码平台普遍缺乏这种能力或支持薄弱,导致协同开发成本高,迭代效率受限。因此,我们基于低代码系列相关协议,设计了低代码多分支协同开发方案,以降低协同成本,提高研发效率。协议原文:https://lowcode-engine.cn/lowcode低码引擎官网:https://lowcode-engine.cn/index并且希望得到一个基于低码的多人协作解决方案代码引擎系统通过文章。为什么要多人协作?低代码技术在业界流行已久。阿里也有很多低代码平台,其中一个拥有大量的用户和活跃的中后端应用;在用户研究中,大量的用户反馈需要更优化的协作和多分支能力。“低代码协同开发”问题已经成为用户真正关心和痛点。现在是什么问题?我们可以从以下真实场景中体会到目前的困境:当一个页面的开发任务被分给两个学生时,只有一个人可以开发,另一个学生才能开发。;在开发过程中,当线上问题突然需要修复时,需要回滚完成修复,然后重新开发新的需求;多功能并行开发时,需要复制多个页面,最后手动合并schema;由此可见,这个低代码平台存在三个问题:不支持并行开发。这导致开发人员的无所事事,从而限制了开发时间和协作方式。不支持迭代模式。没有隔离,就无法支撑复杂应用生命周期的迭代需求,尤其是对于快速迭代升级的业务,导致迭代成本非常高。无法合并编辑。人工合并流程复杂且不受监管,只能由熟悉协议的专业人员操作,导致合并和验证成本较高。问题分析低代码开发本身的优势在于“成本低”和“速度快”,不能因为协同解决方案而大幅增加开发的复杂度。为了解决上述问题,其实还有一些问题需要考虑:如何“协同”?在考虑并行开发问题时,其实不应该让开发者同时在一个页面上操作,而是通过适当的拆解和解耦;就像在工业生产中一样,一台机器被分解成几个部分,流水线分别完成,然后将零件组装成机器。代码开发也是如此,所以我们需要一套类似于“零件生产”和“零件组装”的能力来支持低代码页面的拆分。如何实现多版本?低代码应用程序的数据都存储在数据库中。如何在数据库中实现分布式版本控制,维护不同的应用版本。你想实现一套基于存储低代码数据的Git数据库吗?如何控制开发复杂度?低代码开发者不同于源代码开发。它们并不面向“代码”本身,所涵盖的人也并非都是专业开发人员。低代码开发者如何熟悉多分支开发流程?不能附上《Git从入门到精通》的副本,强行提高低代码开发的门槛。我们还在系列的第一篇文章《低代码技术在研发团队的应用模式探讨》中讨论了如何进行多人协作。我们整体的策略其实是“刚柔并济”的结合,分为以下两个步骤:弱化:80%的并行开发需求应该拆分,降低耦合度,减少需要的人数联合的可能性开发相同的模块。通过设计应用模块划分,合理拆分组件,尽可能避免需要多人协作的场景。例如:通过微前端拆分大型应用,通过独立发布小应用构建大型应用;拆分组件:抽象更多业务垂直能力,差异化模块开发。这样可以将同一个页面拆分成多个模块,由不同的开发者开发,也提高了复用性和封装性。硬帮:在不得已的情况下,参考源码开发,我们也需要设计一个健壮的分支管理有效管理开发协作、特性迭代和版本并行性的策略,更优雅高效地解决版本控制和合并问题。即:开发者可以从主干中分离出一个分支进行操作,不影响主干,分支之间相互独立,互不影响;分支上开发完成后,可以合并到主干中平台后台如何实现先介绍一下我们程序的后台。目前有一个低代码平台,和大多数低代码应用一样,还不能很好地支持协同开发的需求。后续将介绍如何在本平台上应用这套方案设计。研发流程创建一个新的应用后,可以通过可视化的方式进行开发,包括通过拖拽方式开发表单页面,或者配置导航和主题颜色等。开发完成后,可以将应用发布到日常测试环境,然后就可以发布线上资源了。这样就完成了一个完整的研发周期,待新需求到来后,将开始下一个应用开发。数据存储应用程序的所有数据都以结构化数据格式存储在数据库中。数据包括两种类型。每个应用程序都会有一个全局的应用程序数据,它与多个页面数据相关联。目前的效果在系列文章的第一部分,也讨论了研发过程。可以看到,上文说的《关于 LowCode&ProCode 混合研发的思考》https://mp.weixin.qq.com/s/TY3VXjkSmsQoT47xma3wig我们不想多分支方案带来太多的复杂性,所以保留了原来的研发流程作为一个整体在流程设计中。通过上面设计的策略,做出如下产品设计:并行开发:支持组件化开发通过在项目中支持低代码组件,可以将页面开发需求拆分成组件进行开发,包括:低代码组件+素材描述(优先使用)这里的低代码组件是指通过可视化拖拽和配置产生的组件,具有与react源组件相同的能力。源码组件+素材说明:参考低代码引擎开源项目中提供的组件形式。这两个组件都直接在低代码页面中使用。组件单独开发后,可以集成在低代码页面上。这允许在不同组件中独立并行开发。迭代管理:多分支模式的开发者在创建应用后,通过创建/选择一个迭代在一个独立的迭代中完成自己的研发内容,包括低代码组件和低代码页面的开发;当在当前迭代上开发完成后,可以合并到主干中。下面详细阐述多分支模式的技术方案和实现:技术实现方案设计1.依托Git实现迭代管理既然有Git这么成熟优质的解决方案,那当然是站在巨人肩膀上的选择。通过双向转换,我们将数据库中的元数据转换为中间代码(一种类react前端可以理解的形式)并存储在Git中。利用git的基本能力提供分布式版本控制能力。2.简单的分支策略在整体流程中,我们保留了低代码应用的开发习惯,只揭示迭代的概念,更多的是揭示branching、commit、pull、push等概念,但是将它们整合到发布流程中.开发者无需手动拉主干或提交变更,只需要在自己的迭代中进行开发、测试和发布。即分支开发主干发布的模型:只有一个master作为主干,所有的分支创建都是从master复制拉取;日常发布时,需要合并master的改动;在线发布后,分支合并到master,然后删除。整体流程支持多分支协同解决方案后,应用开发流程如下:创建应用首先会创建一份应用数据的副本,保存在数据库中;然后创建对应的Git仓库,并同步应用的管理员权限;ProjectId存储在应用程序的属性中。创建迭代会在数据库中复制一份完整的数据(迭代应用)。在迭代开发过程中,数据会存储在这个【迭代应用】中。同时Git也会从Master拉取开发分支。开发分支名称与【迭代应用】的版本号一致,作为映射关系。这样每次迭代都是相互独立的,数据是隔离的。用户进入应用后,可以选择不同的迭代进行独立开发。每日发布【DBToGit】应用数据转码并保存到Git分支;[Git]合并主干,依赖Git进行代码合并;如果有冲突,使用WebIDE解决冲突[GitToDB]将分支数据传输到迭代应用程序Applicationpackaging&constructiontransferCodescheme这个过程用于将整个应用程序的内容转换成指定目录结构的文件并提交它到Gitlab。应用程序的所有数据都映射到文件结构中。页面的Schema部分包含视图、数据源、页面Js和样式等数据,并对数据进行拆分。页面schema中的组件树部分通过转码转换为JSX+语法,更符合前端开发者的习惯,方便用户完成冲突解决和代码审查。当JSX+的DSL回归组件树的原始结构时,需要使用抽象语法树,使用babel来解析JSX文件。然后递归遍历语法树,还原出符合《低代码引擎搭建协议规范》的schema结构。在线预发布检查:主干是否更新,审核是否完成等应用打包构建[Git]开发分支合并到Master[DB]在线应用数据扩展能力的迭代应用覆盖率虽然低很多-codeplatformsarelow-levelatbottom使用低代码引擎和协议栈,但同时它们也有自己对协议的扩展。为了满足不同平台的定制化需求,该方案需要具备一定的扩展能力,以适应更多平台的使用需求。基于《低代码引擎搭建协议规范》的标准协议,我们设计了相应的标准多分支编码器,同时也提供了多种钩子来扩展协议。在日常和在线服务的发布中,也有设计自定义数据的方式:dbToGitHook:供上层平台自定义提交到Git的数据;beforeGitToDbHook:提供合并master后的Git内容,上层平台返回修改后的GitStructure;不改变gitorigin信息,只作为执行的源文件传回数据库。可视化多分支协同以上方案已经开始应用于企业智能部门的低代码平台,但目前的方案仅处于“可用”状态,仍存在“不易落地”的问题使用”。其中最突出的是“水土不服”的问题。目前的多分支是参考源码研发系统的多分支玩法设计建立的,与低代码使用场景有很多不??一致的地方:不理解:一般反馈不理解冲突解析困难,看不懂DSL中的属性;碎片感:从低代码平台跳转到WebIDE编辑代码,不符合低代码操作直觉;不可控:自动合并后发布时,发生了什么变化,合并后的结果是不确定的;所以我们会继续构建好用的多分支解决方案,构建适合低代码思维的多分支研发体验,提供统一的“可视化”解决方案,彻底解决这个问题。包括:VisualDiff:使用visualDiff来帮助用户在在线发布之前确认修改;VisualCR:Reviewer可以将开发者所做的所有改动可视化,在上线前做出更好的判断;视觉合并:是通过单击选择要保留的冲突。其中,我们目前针对visualDiff&CR的产品设计是这样的:可以查看开发分支和线上主分支的差异(也就是变化点),可以清晰直观的展示需要注意的变化.tupian的整体设计方案是根据transformationDSL内容计算变化信息,将迭代的所有变化点可视化;当发生合并冲突时,列出冲突信息,以便开发者可以点击保留想要更改的内容。总结展望未来,通过这套完善的解决方案,构建低代码多分支解决方案规范,打造契合LowCode场景的协同开发体验。欢迎关注阿里低代码引擎,了解更多低代码构建相关技术。https://lowcode-engine.cn也欢迎进入低码引擎官方微信群进行更多交流,只需添加微信号wxidvlalalalal并备注“低码引擎,申请入群”即可。