作者：黃也(胖丁)

引言

隨著低程式碼的普及，在低程式碼平臺上構建企業級應用逐漸成為生產趨勢。同時，隨著低程式碼技術的提升，越來越多的複雜應用在低程式碼平臺中完成。在其研發生命週期中，低程式碼開發者就會面臨多人協作、並行開發、維護多版本的場景。而現有的低程式碼平臺普遍缺乏這一能力或支援較弱，導致對協同開發的成本較高，限制了迭代的效率。

因此我們基於低程式碼系列相關協議，設計了低程式碼多分支協同開發的解決方案，以降低協同成本、提高研發效能。

協議原文：http://lowcode-engine.cn/lowcode

低程式碼引擎官網：http://lowcode-engine.cn/index

本文適合對低程式碼引擎有基本瞭解的人，瞭解低程式碼引擎的基礎協議，並且希望通過文章中得到基於低程式碼引擎體系的多人協作方案。

為什麼要做多人協同

低程式碼技術在業界已經流行了相當長一段時間了，在阿里內部也有很多低程式碼平臺，其中某平臺具有較多的使用者量和活躍的中後臺應用；在該平臺持續的使用者調研中，大量使用者反饋需要更加優化的協同、多分支能力。“低程式碼協同開發”問題成為了使用者切實的顧慮和痛點。

現在有什麼問題

我們可以從下面幾個真實的場景中，來感受一下當前的困境：

• 當一個頁面的開發任務拆分給了兩名同學，就只能一人開發完之後，另外一個同學才能進行開發；

• 當開發的過程中，突然需要修復線上問題，就需要回滾完成修復後，再重頭開發新的需求；

• 當多功能並行開發時，就需要複製多份頁面，最後再人工進行 schema 合併；

由此我們可以看出來這個低程式碼平臺有三個問題：

• 不支援並行開發。 導致開發人員的閒置，限制了開發時長和協同方式。

• 不支援迭代模式。不具備隔離性，無法支援複雜應用生命週期的迭代需求，尤其對於快速迭代升級的業務，導致迭代成本非常高。

• 無法合併修改。複雜、無規範的手動合併流程，只有對協議很熟悉的專業人士才能操作，導致合併和驗證成本提高。

問題分析

低程式碼開發本身的優勢就在於“成本低”、“速度快”，不能因為協同方案而導致開發複雜度大幅提高。以此想要解決以上的問題，其實有一些需要考慮的問題：

• 如何“協同”？

在考慮並行開發問題時，其實不應讓開發者同時在一個頁面裡同時操作，而是通過適當的進行拆分解耦；就像在工業生產時，一個機器分解為若干個零件，流水線分別完成零件後再組裝成機器。在程式碼開發時也是如此，那麼我們就需要一套類似“零件生產”、“零件組裝”的能力，來支援拆分低程式碼頁面。

• 如何實現多版本？

低程式碼應用的資料都儲存在資料庫中，怎麼在資料庫中實現分散式版本控制，維護不同的應用版本。難道要實現一套基於儲存低程式碼資料資料庫的 Git嗎 ？

• 如何控制開發複雜度？

低程式碼開發者不同於原始碼開發，他們本身就不是面向“程式碼”本身，覆蓋的人群也不全都是專業開發人員，怎麼才能讓低程式碼開發者熟悉多分支開發的流程呢。總不能附上一份《Git從入門到精通》，強行提高低程式碼開發的門檻。

怎麼做多人協同

這個問題在系列文章的前篇《低程式碼技術在研發團隊的應用模式探討》中，我們也做出了探討。

我們的整體策略其實是**“剛柔並濟”**的組合拳，分為了以下兩步走：

• 削弱：

80% 的並行開發需求都應該通過拆分顆粒度的方式，來降低耦合度、減少必須多人共同開發同一模組的可能性。可以通過設計應用模組劃分、合理拆分元件，儘可能的規避需要多人協作的場景。比如：

1. 通過微前端，將大型應用拆分，通過獨立釋出功能的小應用來構建大型應用；

2. 拆分**元件：抽象更多業務垂直的能力，區分模組開發。這樣同一頁面就可以拆分為多個模組，由不同的開發人員開發，也提高了複用性和封裝性。**

• 硬剛：

在不可避免的情況下，參照原始碼開發，我們也需要設計一個健壯的**分支管理策略，**來有效管理開發協作、功能迭代和版本並行，更優雅更高效的解決版本控制和合並問題。也就是：

1. 開發者可以從主幹上分離出來一個分支進行操作，既不影響主幹，分支之間也相互獨立、互不影響；

2. 當在分支上開發完畢後，可以合併到主幹上

如何實現

平臺背景

首先介紹下我們這套方案的背景。當前有一款低程式碼平臺，同大部分低程式碼應用一樣，暫時還不能很好的支援協同開發的需求。後續將介紹如何在該平臺上應用這套方案設計。

• 研發流程

新建應用後，就可以通過視覺化的方式進行研發，包括以拖拽方式對錶單頁面進行開發，或者對導航、主題色等進行配置。待完成開發後，即可以將應用釋出到日常環境進行測試，接著釋出線上資源。

這就完成了一個完整的研發週期，待新需求到來後，再開始下一次的應用開發。

• 資料儲存

應用的所有資料，都是以結構化資料的格式儲存於資料庫中。資料包括了兩種型別，每個應用都會有一份全域性的應用資料，關聯多個頁面資料。

當前效果

在系列文章的前篇中，也對研發流程做出了探討。可見《關於 LowCode&ProCode 混合研發的思考》http://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 場景的協同開發體驗。

歡迎關注阿里低程式碼引擎，瞭解更多低程式碼搭建相關技術。

http://lowcode-engine.cn

也歡迎到低程式碼引擎官方微信群進行更多交流，加微訊號 wxidvlalalalal 並備註「低程式碼引擎，申請入群」即可。