关于低代码:低代码多分支协同开发的建设与实践

作者：黄也(胖丁)

引言

随着低代码的遍及，在低代码平台上构建企业级利用逐步成为生产趋势。同时，随着低代码技术的晋升，越来越多的简单利用在低代码平台中实现。在其研发生命周期中，低代码开发者就会面临多人合作、并行开发、保护多版本的场景。而现有的低代码平台广泛不足这一能力或反对较弱，导致对协同开发的老本较高，限度了迭代的效率。

因而咱们基于低代码系列相干协定，设计了低代码多分支协同开发的解决方案，以升高协同老本、进步研发效力。

协定原文：https://lowcode-engine.cn/lowcode
低代码引擎官网：https://lowcode-engine.cn/index

本文适宜对低代码引擎有根本理解的人，理解低代码引擎的根底协定，并且心愿通过文章中失去基于低代码引擎体系的多人合作计划。

为什么要做多人协同

低代码技术在业界曾经风行了相当长一段时间了，在阿里外部也有很多低代码平台，其中某平台具备较多的用户量和沉闷的中后盾利用；在该平台继续的用户调研中，大量用户反馈须要更加优化的协同、多分支能力。“低代码协同开发”问题成为了用户切实的 顾虑 和痛点。

当初有什么问题

咱们能够从上面几个实在的场景中，来感受一下以后的窘境：

• 当一个页面的开发工作拆分给了两名同学，就只能一人开发完之后，另外一个同学能力进行开发；
• 当开发的过程中，忽然须要修复线上问题，就须要回滚实现修复后，再重头开发新的需要；
• 当多功能并行开发时，就须要复制多份页面，最初再人工进行 schema 合并；

由此咱们能够看进去这个低代码平台有三个问题：

• 不反对并行开发。导致开发人员的闲置，限度了开发时长和协同形式。
• 不反对迭代模式。不具备隔离性，无奈反对简单利用生命周期的迭代需要，尤其对于疾速迭代降级的业务，导致迭代老本十分高。
• 无奈合并批改。简单、无标准的手动合并流程，只有对协定很相熟的专业人士能力操作，导致合并和验证老本进步。

问题剖析

低代码开发自身的劣势就在于“成本低”、“速度快”，不能因为协同计划而导致开发复杂度大幅提高。以此想要解决以上的问题，其实有一些须要思考的问题：

• 如何“协同”？

在思考并行开发问题时，其实不应让开发者同时在一个页面里同时操作，而是通过适当的进行拆合成耦；就像在工业生产时，一个机器合成为若干个整机，流水线别离实现整机后再组装成机器。在代码开发时也是如此，那么咱们就须要一套相似“整机生产”、“整机组装”的能力，来反对拆分低代码页面。

• 如何实现多版本？

低代码利用的数据都存储在数据库中，怎么在数据库中实现分布式版本控制，保护不同的利用版本。难道要实现一套基于存储低代码数据数据库的 Git 吗？

• 如何管制开发复杂度？

低代码开发者不同于源码开发，他们自身就不是面向“代码”自身，笼罩的人群也不全都是业余开发人员，怎么能力让低代码开发者相熟多分支开发的流程呢。总不能附上一份《Git 从入门到精通》，强行进步低代码开发的门槛。

怎么做多人协同

这个问题在系列文章的前篇《低代码技术在研发团队的利用模式探讨》中，咱们也做出了探讨。

咱们的整体策略其实是 “刚柔并济” 的组合拳，分为了以下两步走：

• 减弱：

80% 的并行开发需要都应该通过拆分颗粒度的形式，来升高耦合度、缩小必须多人共同开发同一模块的可能性。能够通过设计利用模块划分、正当拆分组件，尽可能的躲避须要多人合作的场景。比方：

1. 通过 微前端，将大型利用拆分，通过独立公布性能的小利用来构建大型利用；
2. 拆分 组件：形象更多业务垂直的能力，辨别模块开发。这样同一页面就能够拆分为多个模块，由不同的开发人员开发，也进步了复用性和封装性。

• 硬刚：

在不可避免的状况下，参照源码开发，咱们也须要设计一个强壮的 分支管理策略，来无效治理开发合作、性能迭代和版本并行，更优雅更高效的解决版本控制和合并问题。也就是：

1. 开发者能够从骨干上分离出来一个分支进行操作，既不影响骨干，分支之间也互相独立、互不影响；
2. 当在分支上开发结束后，能够合并到骨干上

如何实现

平台背景

首先介绍下咱们这套计划的背景。以后有一款低代码平台，同大部分低代码利用一样，临时还不能很好的反对协同开发的需要。后续将介绍如何在该平台上利用这套方案设计。

• 研发流程

新建利用后，就能够通过可视化的形式进行研发，包含以拖拽形式对表单页面进行开发，或者对导航、主题色等进行配置。待实现开发后，即能够将利用公布到日常环境进行测试，接着公布线上资源。

这就实现了一个残缺的研发周期，待新需要到来后，再开始下一次的利用开发。

• 数据贮存

利用的所有数据，都是以结构化数据的格局存储于 数据库 中。数据包含了两种类型，每个利用都会有一份全局的 利用数据 ，关联多个 页面数据。

以后成果

在系列文章的前篇中，也对研发流程做出了探讨。可见《对于 LowCode&ProCode 混合研发的思考》https://mp.weixin.qq.com/s/TY3VXjkSmsQoT47xma3wig

前文提到了不想由多分支计划带来过高的复杂度，因而咱们在流程设计上，整体保留原有研发流程。通过上文中设计的策略，做出了以下的产品设计：

• 并行开发：反对组件研发

通过反对我的项目内低代码组件的形式，能够将页面开发需要拆分为组件进行开发，包含：

• 低代码组件 + 物料形容（优先应用）

  • 这里低代码组件指的是：通过可视化的拖拽、配置的形式生产的组件，具备与 react 源码组件等同的能力。

• 源码组件 + 物料形容：

  • 参考低代码引擎开源我的项目中提供的组件模式。

这两种组件都在低代码页面中间接应用。待组件别离研发结束后，既能够在低代码页面做实现集成。这样就能够在不同的组件中进行独立并行研发。

• 迭代治理：多分支模式

开发者在创立利用后，通过创立 / 抉择迭代，在 独立的迭代 中实现本人的研发内容，包含低代码组件和低代码页面的研发；当在以后迭代上开发结束后，能够 合并 到骨干上。

下文就多分支模式的技术计划和实现，做出具体的论述：

技术实现

方案设计

1. 依附 Git 实现迭代治理

既然有 Git 如此成熟且优质的解决方案，当然是抉择站在伟人的肩膀上。咱们通过双向转换，将数据库中的元数据，通过出码转为为两头码（react-like 前端可了解的模式）并存储在 Git 中。应用 git 的根底能力，来提供分布式版本控制能力。

2. 简略的分支策略

整体流程上，咱们保留了低代码利用的开发习惯，只透出迭代的概念，不过多透出分支、commit、pull、push 等概念，而是将其融入公布流程。开发者不须要手动拉取骨干或者提交批改，只须要 work in 本人的迭代中，进行开发、测试和公布。也就是的 分支开发、骨干公布 的模式：

• 仅有一条 master 作为骨干，所有的分支创立都从 master 复制拉取；
• 公布日常时，须要合并 Master 的批改；
• 公布线上后，分支并入 Master 后删除。

整体流程

在反对多分支协同计划后，利用的研发流程如下：

创立利用

会先创立一份利用的数据，保留在数据库中；再创立对应的 Git 仓库，同步利用的管理员权限；将 Git 仓库的 ProjectId 存储于利用的属性中。

创立迭代

会在数据库中复制一份残缺的数据（迭代利用），在迭代的开发过程中，数据都保留在这份【迭代利用】中。同时 Git 也会从 Master 拉取开发分支，开发分支的名称与【迭代利用】的版本号保持一致，以此作为映射的关联关系。这样各个迭代之间就互相独立、数据隔离。

用户进入利用后，就能够抉择不同的迭代进行独立的开发了。

公布日常

1. [DBToGit] 利用数据转码，保留到 Git 分支；[Git] 合并骨干，依附 Git 进行代码合并；如果有抵触，应用 WebIDE 解决抵触
2. [GitToDB] 分支数据转存到迭代利用
3. 利用打包 & 构建

转码计划

该流程用于将整个利用的内容转换为指定目录构造的文件并提交至 Gitlab。利用的所有数据都被映射到文件构造中。

页面中的 Schema 局部蕴含了视图、数据源、页面 Js 和款式等数据，对数据做出拆分。

页面 Schema 中的组件树局部通过转码转为 JSX+ 语法，更加合乎前端开发者的习惯，不便用户实现抵触解决和代码评审。

在 JSX+ 的 DSL 转回组件树原构造时，须要用到形象语法树，利用 babel 来解析 JSX 文件。再递归遍历语法树，还原回合乎《低代码引擎搭建协定标准》的 schema 构造。

公布线上

1. 公布线上前查看: 骨干是否有更新，是否实现评审等
2. 利用打包 & 构建
3. [Git] 开发分支合并到 Master
4. [DB] 迭代利用笼罩线上利用数据

拓展能力

尽管很多低代码平台底层都是应用低代码引擎和协定栈，然而同时他们也有本人的对于协定的扩大。为了满足不同平台的定制化诉求，此计划须要肯定的拓展能力，来适应更多平台的应用诉求。

1. 基于《低代码引擎搭建协定标准》的标准协议，咱们设计了对应的规范多分支编码器，同时也提供了多种钩子，方面对协定进行拓展。

2. 在公布日常和公布线上的服务上，也对应设计定制数据的形式：

dbToGitHook： 供下层平台定制提交到 Git 的数据内；

beforeGitToDbHook： 提供合并了 master 后的 Git 内容，下层平台返回批改后的 Git 构造；不扭转 git origin 信息，只作为执行转回到数据库的源文件。

可视化多分支协同

以上计划目前曾经在企业智能部门的低代码平台开始应用，但目前的计划还只是刚刚“可用”状态，仍然还存在“不好用”的问题。其中最突出的就是“水土不服”问题，目前的多分支是参考源码研发体系的多分支玩法设计和建设的，和低代码的应用场景有十分多不符合的点：

• 看不懂 ：广泛反馈看不懂 抵触解决困难，不能了解 DSL 中的属性；
• 割裂感 ：从低代码平台跳转到 WebIDE 去 编辑代码，不合乎低代码操作直觉；
• 不可控 ：主动合并后公布时，对于 有什么改变 、 合并后果 没有把握；

所以咱们将会持续建设好用的多分支解决方案，建设 符合低代码心智的多分支研发体验，提供对立的“可视化”解决方案，彻底解决这个问题。包含：

• 可视化 Diff：应用可视化的 Diff，帮忙用户确认公布线上前的改变点；
• 可视化 CR：评审者能够可视化得看到开发者所有的批改，更好的做上线前的判断；
• 可视化 Merge：能够通过点选抉择保留的抵触。

其中，咱们目前对于 可视化 Diff& CR 的产品设计如下：

1. 可能查看 该开发分支 和 线上主分支 的差别（即改变点）
2. 可能 清晰的、可视化的 展现须要关注的改变

tupian

整体设计方案，是依据转化的 DSL 内容计算出变更的信息，通过可视化得呈现出改迭代的所有改变点；而产生合并抵触时，列出抵触的信息让开发者能够通过 点选操作，来保留所需的改变内容。

总结瞻望

将来，将通过这一套欠缺的解决方案，建设低代码多分支解决方案标准，打造符合 LowCode 场景的协同开发体验。

欢送关注阿里低代码引擎，理解更多低代码搭建相干技术。

https://lowcode-engine.cn

也欢送到低代码引擎官网微信群进行更多交换，加微信号 wxidvlalalalal 并备注「低代码引擎，申请入群」即可。