作者簡介

ck，攜程后端開發(fā)專家，關(guān)注技術(shù)架構(gòu)、高并發(fā)、性能調(diào)優(yōu)等領(lǐng)域；

Geralt，攜程前端開發(fā)專家，關(guān)注前端框架及性能優(yōu)化；

Kaoru，攜程資深前端開發(fā)工程師，關(guān)注前端性能及開發(fā)工具；

概述

PGClowcode平臺(tái)是攜程市場(chǎng)內(nèi)容PGC團(tuán)隊(duì)搭建的主要用于后臺(tái)頁面開發(fā)的低代碼平臺(tái)，第一版于23年3月上線，截至10月平臺(tái)已經(jīng)擁有100+用戶，在平臺(tái)上開發(fā)了130+個(gè)應(yīng)用和180+個(gè)頁面。本文將主要介紹團(tuán)隊(duì)采用低代碼平臺(tái)的背景、方案調(diào)研、落地過程中遇到的問題以及解決方案，同時(shí)也大致介紹了該低代碼平臺(tái)提供的能力。

一、研究背景

1.1 為什么需要低代碼平臺(tái)

軟件產(chǎn)品通常由客戶端（App、小程序、網(wǎng)頁）和運(yùn)營后臺(tái)組成，其整個(gè)生命周期需要不斷地更新迭代，而在實(shí)際的迭代開發(fā)中經(jīng)常會(huì)出現(xiàn)以下問題：

• 后臺(tái)需求優(yōu)先級(jí)低，排期經(jīng)常被延期，通常使用配置中心等簡易數(shù)據(jù)操作平臺(tái)替代，不僅對(duì)運(yùn)營人員不友好，而且產(chǎn)生了極大的生產(chǎn)風(fēng)險(xiǎn)
• 迭代需求涉及的前后端開發(fā)工作量不均衡，經(jīng)常面臨后臺(tái)需求較多，但前端資源不足，服務(wù)端資源即便有空閑也沒法幫忙支持后臺(tái)的需求
• 不同業(yè)務(wù)間后臺(tái)技術(shù)和組件大同小異，各業(yè)務(wù)反復(fù)造輪子，浪費(fèi)時(shí)間和資源
• 開發(fā)人員開發(fā)工具類站點(diǎn)時(shí)，頁面部分的工作需要付出較大的代價(jià)

針對(duì)這些問題我們也嘗試了很多的解決方案，如要求開發(fā)人員全棧、剝離公共組件等，但結(jié)果都不太理想，經(jīng)過充分的了解和分析，搭建低代碼或零代碼平臺(tái)能在很大程度上解決這些問題。

1.2 需要什么樣的低代碼平臺(tái)

低代碼平臺(tái)分為很多種，我們究竟需要哪種呢？經(jīng)過將以上問題拆分細(xì)化和充分調(diào)研后，我們的低代碼平臺(tái)應(yīng)該滿足以下要求：

頁面搭建方面：

• 界面友好、可視化，可以讓研發(fā)和相關(guān)人員能通過拖拽的簡單方式快速搭建UI
• 頁面邏輯僅需寫少量簡單的代碼或無需代碼
• 支持滿足日常需求的組件庫

部署運(yùn)維方面：

具有開發(fā)、部署、運(yùn)維等完整的持續(xù)交付功能，最好能一鍵或自動(dòng)化完成

安全合規(guī)方面：

• 支持權(quán)限管理機(jī)制，保證系統(tǒng)安全
• 具備完善的發(fā)布審批機(jī)制，能嚴(yán)格保證開發(fā)質(zhì)量和生產(chǎn)安全

兼容性方面：

能嵌入已有后臺(tái)頁面，已有后臺(tái)盡量少改動(dòng)的嵌入其開發(fā)的頁面

可擴(kuò)展性方面：

支持用戶自助化組件開發(fā)，并且能在平臺(tái)上推廣

二、現(xiàn)狀分析

2.1 行業(yè)現(xiàn)狀

目前國內(nèi)外低代碼或零代碼產(chǎn)品不下百種，既有商業(yè)平臺(tái)，也有開源項(xiàng)目，它們?cè)谄髽I(yè)內(nèi)部用于各種運(yùn)營后臺(tái)、數(shù)據(jù)面板、辦公系統(tǒng)等內(nèi)部系統(tǒng)的開發(fā)，在B端提供商品管理、廣告投放、商鋪搭建等企業(yè)服務(wù)，在C端廣泛用于活動(dòng)頁面、促銷頻道、廣告頻道等類型產(chǎn)品的搭建，不僅為企業(yè)節(jié)省了大量的開發(fā)成本、產(chǎn)生巨大的商業(yè)價(jià)值，同時(shí)也為用戶提供了豐富多彩的軟件產(chǎn)品。

雖然低代碼種類繁多，但是每類低代碼項(xiàng)目往往具有特定的業(yè)務(wù)屬性，在不同的行業(yè)，不同的公司可能需要定制不同的組件，不同的流程，因此市場(chǎng)上很少有能適用于所有場(chǎng)景的平臺(tái)，也很少有企業(yè)愿意去做通用平臺(tái)。下面分析了目前比較流行的產(chǎn)品：

2.2 產(chǎn)品分析

阿里低代碼引擎

LowCodeEngine（阿里低代碼引擎）是國內(nèi)最知名的低代碼類產(chǎn)品之一，其完整的實(shí)現(xiàn)了《低代碼引擎搭建協(xié)議規(guī)范》和《低代碼引擎物料協(xié)議規(guī)范》，它通過完整的協(xié)議棧約定了各種物料的開發(fā)、使用、擴(kuò)展、流通，并且提煉了企業(yè)級(jí)低代碼平臺(tái)的特性，遵循面向擴(kuò)展設(shè)計(jì)的理念，奉行最小內(nèi)核、最強(qiáng)生態(tài)的設(shè)計(jì)原則而設(shè)計(jì)的內(nèi)核引擎。

目前其生態(tài)已經(jīng)相當(dāng)完備，并且提供了非常詳細(xì)的文檔和使用案例，也有大量的demo開源，其使用起來相對(duì)比較便捷。但它并沒有提供完整的平臺(tái)代碼，使用者需要在其內(nèi)核的基礎(chǔ)上搭建面向用戶的平臺(tái)和服務(wù)系統(tǒng)，具有相當(dāng)?shù)拈_發(fā)成本。

騰訊低代碼平臺(tái)

騰訊的低代碼產(chǎn)品包括搭建生成移動(dòng)端H5頁面的tmagic-editor開源項(xiàng)目和搭建管理端頁面的無極低代碼商業(yè)平臺(tái)，其中tmagic-editor提供了完整的平臺(tái)代碼，使用者可以在開源社區(qū)將整個(gè)項(xiàng)目pull到本地部署使用，它具備自定義組件、插件、編輯器等擴(kuò)展能力，內(nèi)置了豐富的組件，提供了友好的可視化界面，通過拖拽+配置的方式開發(fā)頁面。

但其限定于移動(dòng)端H5頁面的搭建，無法適用pc端頁面開發(fā)的需求，大大限制了使用范圍。無極低代碼平臺(tái)是商業(yè)化的面向企業(yè)付費(fèi)使用的產(chǎn)品，具備管理端強(qiáng)大的開發(fā)能力，甚至結(jié)合了AI能力，能供面向企業(yè)豐富的解決方案，但它目前并沒有開源。

開源低代碼平臺(tái)

在github上搜索lowcode關(guān)鍵詞可以看到非常多的項(xiàng)目，他們所使用的技術(shù)、項(xiàng)目的形態(tài)、star數(shù)量、活躍的層度、使用場(chǎng)景各不相同，有些提供了完整的可視化界面，有些則需要通過配置文件或調(diào)用接口的方式生成頁面或項(xiàng)目，總之需要花費(fèi)較多的時(shí)間對(duì)比分析才能找到符合自身需求的項(xiàng)目。

總結(jié)

綜上所述，我們最終決定選擇一款開源程度比較高的項(xiàng)目（appsmith）作為藍(lán)本，然后經(jīng)過改造、開發(fā)搭建了PGClowcode平臺(tái)。?

三、平臺(tái)功能介紹

PGClowcode平臺(tái)功能主要包含頁面搭建、組件開發(fā)平臺(tái)兩大部分。

頁面搭建包含開發(fā)、預(yù)覽、測(cè)試、發(fā)布、回滾、備份、恢復(fù)等常用功能。在這些功能的基礎(chǔ)上，增加了"可視化拖拽"、"多用戶協(xié)同開發(fā)"、"導(dǎo)入導(dǎo)出"、"多數(shù)據(jù)源"、"通知"等功能，形成了一個(gè)相當(dāng)完善的開發(fā)體系。搭建的產(chǎn)物可以通過將平臺(tái)上的應(yīng)用或頁面嵌入到已有的后臺(tái)，或者反過來將已有的后臺(tái)頁面嵌入到平臺(tái)，實(shí)現(xiàn)組合使用。

組件開發(fā)平臺(tái)是對(duì)頁面搭建能力的擴(kuò)展，支持通過CLI構(gòu)建本地項(xiàng)目，自定義開發(fā)新的組件以滿足更復(fù)雜的業(yè)務(wù)需求。（此功能正在開發(fā)中，將在不久之后開放）

由于篇幅有限，下面將介紹幾個(gè)主要功能。

3.1 用戶和權(quán)限管理

平臺(tái)擁有自己的用戶管理體系，為了與攜程的賬號(hào)體系打通，接入了OIDC域賬號(hào)認(rèn)證，使用者無需額外注冊(cè)賬號(hào)，只需要使用攜程域賬號(hào)登錄即可。

用戶的權(quán)限做了充分的拆分，平臺(tái)的所有功能對(duì)每個(gè)用戶開放，只是對(duì)于用戶私有的數(shù)據(jù)做了權(quán)限控制，權(quán)限定義的最小單位是工作空間（workspace），用戶可以擁有多個(gè)workspace，每個(gè)workspace 定義了管理員（admin）、開發(fā)者（developer）、使用者（viewer）、測(cè)試者（tester）、審核者（reviewer）五個(gè)權(quán)限組。其中每個(gè)權(quán)限組對(duì)workspace下面的資源擁有不同的管理權(quán)限，這些資源包括數(shù)據(jù)源、應(yīng)用、頁面等，admin可以對(duì)workspace內(nèi)的用戶分配不同的權(quán)限組，從而對(duì)應(yīng)用的開發(fā)、發(fā)布等流程上進(jìn)行管理。具體各權(quán)限組的權(quán)限分配參考下表：

 3.2 可視化應(yīng)用開發(fā)

傳統(tǒng)后臺(tái)開發(fā)與采用低代碼平臺(tái)進(jìn)行后臺(tái)開發(fā)的流程區(qū)別如下圖所示：

傳統(tǒng)后臺(tái)開發(fā)過程中需要開發(fā)者自身搭建開發(fā)環(huán)境，引入前端組件庫如Ant Design，相同的功能需要自己提取組件，開發(fā)效率低效。

PGClowcode低代碼平臺(tái)提供了可視化拖拽的面板，支持頁面復(fù)雜布局。組件欄支持40+種通用組件，并可以組合使用。

在頁面繪制方面，通過將其拖入畫板，調(diào)整位置布局，簡單幾步完成界面的設(shè)計(jì)，做到了所見即所得。相同功能可以在畫布中復(fù)制粘貼，應(yīng)用本身也支持導(dǎo)入導(dǎo)出功能，方便項(xiàng)目復(fù)制。開發(fā)變得靈活高效，避免了一些基本構(gòu)建所產(chǎn)生的bug，達(dá)到了降本增效的效果。

在組件的屬性值設(shè)定方面，可以通過可視化的輸入或者通過自定義JS代碼的方式進(jìn)行復(fù)雜的邏輯綁定，并且也支持編寫js代碼完成復(fù)雜的交互邏輯。平臺(tái)內(nèi)置了多種js庫，可以將數(shù)據(jù)綁定到組件上，在開發(fā)狀態(tài)下能立即看到數(shù)據(jù)渲染的效果，使得在預(yù)覽狀態(tài)下可以邊開發(fā)邊自測(cè)。

3.3 流程管理

應(yīng)用從開發(fā)態(tài)->測(cè)試態(tài)->發(fā)布態(tài)的流轉(zhuǎn)十分便利。平臺(tái)設(shè)計(jì)了不同角色，將測(cè)試、審核的流程精簡化，各角色登錄后可以看到應(yīng)用的不同狀態(tài)，應(yīng)用在開發(fā)和審批后自動(dòng)流轉(zhuǎn)至下一狀態(tài)，只需要簡單幾個(gè)流程即可完成。

1）開發(fā)人員（開發(fā)態(tài)）：根據(jù)需求搭建、開發(fā)頁面，然后發(fā)布到測(cè)試環(huán)境；

2）測(cè)試人員（測(cè)試態(tài)）：在頁面測(cè)試，保證其能滿足需求，且不存在質(zhì)量問題后點(diǎn)擊Publish提交發(fā)布申請(qǐng)；

3）審核人員（發(fā)布態(tài)）：在“待我審核”列表中找到審核申請(qǐng)。審批通過，應(yīng)用自動(dòng)完成發(fā)布。

3.4 備份與還原

開發(fā)平臺(tái)支持了應(yīng)用數(shù)據(jù)的備份和歷史版本數(shù)據(jù)的還原。在開發(fā)狀態(tài)下平臺(tái)采用了自動(dòng)保存的設(shè)計(jì)方案，由于多人同時(shí)開發(fā)時(shí)容易出現(xiàn)相互覆蓋或操作沖突的情況，為了減少這種問題導(dǎo)致的返工成本，我們?cè)O(shè)計(jì)了備份和還原的功能。

和正常普通的應(yīng)用一樣，用戶可以將每個(gè)穩(wěn)定版本的開發(fā)態(tài)備份到系統(tǒng)，在之后的操作中需要回到某個(gè)穩(wěn)定版本則直接選中目標(biāo)版本還原即可。

下圖展示了備份還原的操作界面。

四、架構(gòu)和技術(shù)

PGClowcode平臺(tái)采用了前后端分離架構(gòu)。前端使用了react技術(shù)棧，并且集成了攜程的多種公共框架和組件，依托于攜程的CI/CD平臺(tái)，實(shí)現(xiàn)了持續(xù)開發(fā)和交付的能力。服務(wù)端采用spring webflux框架，集成了cat、clog（攜程日志系統(tǒng)）、mongo、credis（攜程redis client）、qconfig(攜程配置中心中間件，下文簡稱QC)、qmq（攜程MQ中間件）等技術(shù)框架，完全融入了攜程的服務(wù)技術(shù)棧，可以通過gitlab自動(dòng)化編譯打包，在captain（攜程發(fā)布平臺(tái)）上發(fā)布。

4.1 架構(gòu)

如上圖所示，PGClowcode平臺(tái)的整體架構(gòu)分為應(yīng)用層、基礎(chǔ)設(shè)施、服務(wù)層、數(shù)據(jù)層。

應(yīng)用層是終端的兩套平臺(tái)系統(tǒng)，主要包括面向用戶的低代碼開發(fā)平臺(tái)和面向開發(fā)人員的組件開發(fā)平臺(tái)。

基礎(chǔ)設(shè)施主要包含前端的基礎(chǔ)框架、數(shù)據(jù)流控制以及抽象出來的前端可視的組件、頁面和編輯器等概念?；A(chǔ)框架主要依托于React App和canvas技術(shù)通過axios庫和服務(wù)端進(jìn)行數(shù)據(jù)交互，通過Redux及相關(guān)插件來控制整個(gè)平臺(tái)的數(shù)據(jù)流，最終展示成用戶可見的組件、頁面、編輯器等UI模塊。

服務(wù)層主要由web層、service層和數(shù)據(jù)訪問層組成，主要提供權(quán)限驗(yàn)證、流程管控、插件管理、消息通知、數(shù)據(jù)訪問等服務(wù)。服務(wù)采用了微服務(wù)架構(gòu)的設(shè)計(jì)，按照不同的領(lǐng)域和功能拆分成領(lǐng)域服務(wù)、通知服務(wù)和插件服務(wù)。

領(lǐng)域服務(wù)又根據(jù)不同的model細(xì)分為不同的模塊，各自完成獨(dú)立單一的功能；通知服務(wù)主要用于email、trippal、sms等消息通知；插件服務(wù)主要提供插件的加載、初始化、調(diào)用、卸載等相關(guān)功能的服務(wù)。數(shù)據(jù)訪問在核心服務(wù)的下層，實(shí)現(xiàn)了針對(duì)多種數(shù)據(jù)源的訪問和數(shù)據(jù)處理、校驗(yàn)的功能。 

數(shù)據(jù)層主要用于存儲(chǔ)元數(shù)據(jù)、應(yīng)用數(shù)據(jù)、插件數(shù)據(jù)等，應(yīng)用的備份數(shù)據(jù)存儲(chǔ)于QC，并且通過QC實(shí)現(xiàn)跨環(huán)境發(fā)布。

下面兩節(jié)主要對(duì)平臺(tái)“組件的可視化拖拽實(shí)現(xiàn)”和“應(yīng)用的開發(fā)-部署實(shí)現(xiàn)”兩項(xiàng)比較核心的技術(shù)詳細(xì)闡述。

4.2 組件的可視化拖拽實(shí)現(xiàn)

可視化拖拽組件是低代碼平臺(tái)的基本功能，在本平臺(tái)中，用戶可以在左側(cè)組件庫里選擇任意組件拖拽到中間的編輯區(qū)域，并更改其大小。

在實(shí)現(xiàn)上述的拖拽功能時(shí)，我們會(huì)面臨幾個(gè)問題：

1）拖拽組件的過程中，組件的位置會(huì)實(shí)時(shí)變更，大量嵌套在一起的dom元素同時(shí)變更位置，會(huì)頻繁觸發(fā)瀏覽器的重繪制，導(dǎo)致性能的消耗。

2）人為的拖拽排布，很難保證組件之間的對(duì)齊和排版，頁面最終效果難以達(dá)到代碼實(shí)現(xiàn)頁面的規(guī)整程度。

對(duì)于上述的問題1，平臺(tái)的解決方案是依托canvas技術(shù)，在組件變更位置或者大小時(shí)，隱藏實(shí)際渲染在頁面上的組件，并在編輯區(qū)域最上層渲染一層canvas，在原組件位置畫出一個(gè)同等大小的色塊來代替原組件，并用以示意用戶，利用canvas畫布的特性來處理組件位置及大小的變更，在用戶結(jié)束拖拽動(dòng)作后，根據(jù)色塊在canvas中的最終位置及大小，重繪制一次組件，并隱藏canvas，展示出組件的最終效果。

在上述描述中可以看到，利用canvas可以極大程度的削減瀏覽器重繪制的次數(shù)，達(dá)到減少性能消耗的目的；選擇色塊來作為繪制對(duì)象而非原組件，既降低了技術(shù)實(shí)現(xiàn)的難度，又進(jìn)一步降低了canvas繪制圖形的性能消耗。

對(duì)于問題2，平臺(tái)的解決方案是陣點(diǎn)系統(tǒng)，當(dāng)用戶拖拽組件到編輯區(qū)域觸發(fā)渲染canvas的同時(shí)，頁面上會(huì)繪制一層陣點(diǎn)并均勻的平鋪在canvas上，當(dāng)用戶在canvas上拖拽色塊變更其位置或者大小時(shí)，在色塊的周邊會(huì)繪制出同等大小的虛線邊框，邊框會(huì)根據(jù)色塊當(dāng)前的位置及大小動(dòng)態(tài)的定位到合適的臨近陣點(diǎn)上。陣點(diǎn)系統(tǒng)中，橫向及縱向兩個(gè)相鄰陣點(diǎn)的間隔即為組件長寬的最小單位，組件的四角位置只能定位在陣點(diǎn)上。由此可見，在拖拽過程中，組件的位置及大小都在一定的限制之內(nèi)，這可以保證最終繪制出來的頁面的規(guī)整性。

以下為一次完整的組件拖拽流程示意圖：

1）頁面無拖拽操作，主編輯區(qū)域僅展示組件的靜態(tài)狀態(tài)，此時(shí)為展示態(tài)。

2）當(dāng)用戶開始拖拽組件以期改變其位置及大小的動(dòng)態(tài)狀態(tài)，為操作態(tài)。操作態(tài)又可以細(xì)化為拖拽開始、拖拽中、拖拽結(jié)束，三個(gè)狀態(tài)。

當(dāng)用戶開始拖拽組件時(shí)，頁面會(huì)從展示態(tài)變更為操作態(tài)。拖拽開始時(shí)，編輯區(qū)域內(nèi)繪制canvas并鋪設(shè)陣點(diǎn)，原組件變?yōu)椴豢梢?，在canvas內(nèi)原組件的相同位置繪制同等大小的色塊以及虛線邊框；在拖拽過程中，色塊會(huì)隨著鼠標(biāo)移動(dòng)變更位置或者大小，其外部虛線邊框也會(huì)隨色塊移動(dòng)或變更大小，并實(shí)時(shí)定位在色塊當(dāng)前位置的最相鄰陣點(diǎn)上；拖拽結(jié)束時(shí)，根據(jù)當(dāng)前邊框的最終大小及位置，重新繪制原組件，并隱藏canvas、陣點(diǎn)系統(tǒng)、色塊以及虛線邊框；頁面由操作態(tài)變更為展示態(tài)，展示出組件的最新狀態(tài)。

4.3 應(yīng)用的開發(fā)-部署實(shí)現(xiàn)

應(yīng)用的開發(fā)和部署的技術(shù)實(shí)現(xiàn)主要分為應(yīng)用的數(shù)據(jù)結(jié)構(gòu)、數(shù)據(jù)流轉(zhuǎn)和多種角色協(xié)同三個(gè)部分，最后針對(duì)應(yīng)用的數(shù)據(jù)備份與還原也做了簡單的介紹。

4.3.1 數(shù)據(jù)結(jié)構(gòu)

當(dāng)前大多數(shù)主流的低代碼平臺(tái)最終的產(chǎn)物可能是代碼，但PGClowcode平臺(tái)最終的產(chǎn)物是數(shù)據(jù)，包括應(yīng)用信息、頁面信息、組件、組件之間的關(guān)系、action、數(shù)據(jù)源等都是以數(shù)據(jù)的形式存儲(chǔ)在db上，由于頁面的布局、組件嵌套、函數(shù)的綁定等各種實(shí)體間關(guān)系非常復(fù)雜，使用傳統(tǒng)的關(guān)系型數(shù)據(jù)庫無法保證數(shù)據(jù)結(jié)構(gòu)穩(wěn)定，因此采用了mongodb作為數(shù)據(jù)庫。應(yīng)用相關(guān)的collection主要包括了plugin、workspace、datasource、application、page、action、actioncollection，它們通過下圖的關(guān)系構(gòu)成了整個(gè)應(yīng)用體系。

plugin主要用于定義平臺(tái)支持插件的元數(shù)據(jù)信息，包括類型、插件包路徑、參數(shù)、狀態(tài)等屬性。

workspace是應(yīng)用開發(fā)的工作空間，它定義了空間內(nèi)的用戶組成、用戶權(quán)限、數(shù)據(jù)源以及支持的插件集合。

application定義了應(yīng)用的名稱、主題、icon、狀態(tài)等基本信息，另外為了查詢便捷，也冗余了部分頁面的信息。

page定義了頁面的名稱、布局、組件、組件的關(guān)系、組件與函數(shù)的綁定關(guān)系等。

datasource定義了外部數(shù)據(jù)訪問的基礎(chǔ)信息，如restapi、es、mongodb等外部數(shù)據(jù)訪問的必要屬性，為了避免重復(fù)配置，它的作用范圍是workspace級(jí)別。

action定義了外部數(shù)據(jù)訪問的具體配置數(shù)據(jù)，它必須依托于datasource，如restapi接口調(diào)用，datasource配置了服務(wù)的域名和是否需要實(shí)時(shí)鑒權(quán)，而action則配置路徑、參數(shù)、運(yùn)行方式，與datasouce不同的是它的作用范圍是頁面。

actionCollection是action或js函數(shù)的集合。

4.3.2 數(shù)據(jù)流轉(zhuǎn)

應(yīng)用數(shù)據(jù)主要是在不同的存儲(chǔ)介質(zhì)和不同的環(huán)境間流轉(zhuǎn)，平臺(tái)目前設(shè)計(jì)了三套環(huán)境FAT、UAT、PRO，平臺(tái)通過QC的跨環(huán)境機(jī)制實(shí)現(xiàn)數(shù)據(jù)流轉(zhuǎn)。

如上圖所示，開發(fā)者在FAT上開發(fā)應(yīng)用，應(yīng)用數(shù)據(jù)以草稿態(tài)存儲(chǔ)于DB，開發(fā)完成后將草稿態(tài)數(shù)據(jù)導(dǎo)出到QC的FAT環(huán)境，服務(wù)監(jiān)聽到QC的數(shù)據(jù)變更將草稿態(tài)copy到發(fā)布態(tài)，測(cè)試則可以在測(cè)試頁面上看到開發(fā)提交的應(yīng)用，測(cè)試完成后提交UAT發(fā)布申請(qǐng)，服務(wù)將發(fā)布態(tài)的數(shù)據(jù)導(dǎo)出到QC的UAT環(huán)境，此時(shí)審核者將收到待審核通知。

進(jìn)入平臺(tái)將待發(fā)布申請(qǐng)審核通過后，UAT環(huán)境的服務(wù)監(jiān)聽到QC數(shù)據(jù)變更將數(shù)據(jù)導(dǎo)入到DB，并且將應(yīng)用數(shù)據(jù)狀態(tài)置為發(fā)布態(tài)，然后可以在UAT的測(cè)試頁面看到發(fā)布態(tài)的應(yīng)用，當(dāng)UAT測(cè)試完成后申請(qǐng)發(fā)布到生產(chǎn)（PRO），UAT服務(wù)將發(fā)布態(tài)應(yīng)用數(shù)據(jù)導(dǎo)出到QC PRO環(huán)境，當(dāng)審核者通過申請(qǐng)后則QC PRO的應(yīng)用文件被發(fā)布，PRO服務(wù)監(jiān)聽到數(shù)據(jù)變更就將應(yīng)用數(shù)據(jù)導(dǎo)入到DB，并置為發(fā)布態(tài)，此時(shí)應(yīng)用的開發(fā)-部署流程結(jié)束，用戶可以在生產(chǎn)環(huán)境的用戶平臺(tái)正常使用了。

4.3.3 多角色協(xié)同

對(duì)于應(yīng)用的開發(fā)、測(cè)試、交付平臺(tái)設(shè)計(jì)了多個(gè)角色，在整個(gè)需求開發(fā)的過程中每個(gè)角色能各司其責(zé)，保證應(yīng)用能持續(xù)、穩(wěn)定、高效迭代交付，如下圖所示。

平臺(tái)通過定義多個(gè)權(quán)限組來區(qū)分每個(gè)角色，當(dāng)workspace被創(chuàng)建時(shí)這些權(quán)限組就會(huì)被創(chuàng)建出來，每個(gè)權(quán)限組定義了各自的權(quán)限，在每個(gè)受權(quán)限管理的資源中都有policies字段，它存儲(chǔ)了能被操作的類型和權(quán)限組id的集合，當(dāng)用戶查詢和操作時(shí)都會(huì)經(jīng)過權(quán)限校驗(yàn)。

有了角色的定義，應(yīng)用開發(fā)人員的協(xié)同就變得簡單多了，如當(dāng)應(yīng)用發(fā)布測(cè)試時(shí)可以自動(dòng)通知測(cè)試人員介入，提交發(fā)布生產(chǎn)申請(qǐng)時(shí)可以自動(dòng)通知審核人員參與審核。

4.3.4 備份與還原

為了方便開發(fā)過程中多人同時(shí)開發(fā)，平臺(tái)設(shè)計(jì)了備份還原功能，當(dāng)用戶點(diǎn)擊備份時(shí)，服務(wù)將當(dāng)前草稿態(tài)數(shù)據(jù)導(dǎo)出到QC，點(diǎn)擊還原則將QC的數(shù)據(jù)導(dǎo)入到服務(wù)，覆蓋當(dāng)前DB中草稿態(tài)數(shù)據(jù)，得益于QC的版本管理功能，每次備份的數(shù)據(jù)都將存儲(chǔ)起來，因此用戶可以還原到歷史的任意版本。

如上圖所示，T1時(shí)刻新增一個(gè)備份v1，T2時(shí)刻QC中存在v1版本的備份數(shù)據(jù)，如果T2時(shí)刻再增加一個(gè)備份v2，到T3時(shí)刻QC存在v1和v2兩個(gè)版本，如果在T3時(shí)刻將DB中的版本還原成v1，則DB中的數(shù)據(jù)會(huì)被還原成v1，與此同時(shí)會(huì)上傳一個(gè)v3版本到QC，實(shí)際上v3和v1數(shù)據(jù)是一樣的，相當(dāng)于將當(dāng)前數(shù)據(jù)的基準(zhǔn)切換到了最新版本，之后的操作都是在這個(gè)版本的基礎(chǔ)上做的，如果再需要還原到這個(gè)基準(zhǔn)就可以快速完成。

五、規(guī)劃與展望

目前PGC低代碼平臺(tái)已經(jīng)具備了非常完整的功能，基本上完成了預(yù)期的目標(biāo)，也產(chǎn)生較大的價(jià)值，但我們對(duì)于它的期望絕非只限于此，并且組建了穩(wěn)定的支持團(tuán)隊(duì)，制定了明確規(guī)劃，在之后的迭代開發(fā)中會(huì)不斷地完善已有的功能和流程，而且會(huì)根據(jù)實(shí)際的需求和業(yè)內(nèi)平臺(tái)的調(diào)研繼續(xù)增加更強(qiáng)大、便捷的功能。

5.1 搭建組件擴(kuò)展平臺(tái)

平臺(tái)原有的組件是比較基本的組件庫，未來會(huì)難以滿足日漸復(fù)雜的業(yè)務(wù)需求，因此自定義組件的需求就會(huì)逐漸凸顯出來，本平臺(tái)基于Appsmith框架是支持自定義組件的，但是原有的自定義功能有如下幾個(gè)問題：

1）原有的自定義組件功能，需要依托于完整的平臺(tái)項(xiàng)目，在其widget文件夾下開發(fā)新組件，項(xiàng)目代碼體量大，啟動(dòng)慢，且以開發(fā)組件為目的頻繁更改提交平臺(tái)項(xiàng)目并不利于平臺(tái)項(xiàng)目的發(fā)布及管理。

2）原有的自定義組件功能并不適合多部門自定義組件的場(chǎng)景，沒有相關(guān)的權(quán)限管理系統(tǒng)，所有自定義組件都會(huì)展示在頁面上，隨著時(shí)間的推移會(huì)造成組件庫的臃腫以及增加編輯頁面時(shí)查找使用組件的費(fèi)力度。

為了解決以上問題，我們會(huì)從主項(xiàng)目中抽離出相關(guān)代碼，搭建一套獨(dú)立的組件開發(fā)項(xiàng)目，以達(dá)到和平臺(tái)主項(xiàng)目分離、代碼純凈、項(xiàng)目快速啟動(dòng)的目的。同時(shí)也會(huì)構(gòu)建一套自定義組件的權(quán)限管理系統(tǒng)以便更好的管理各部門開發(fā)的自定義組件。

5.2 建立模板庫

Ctrl+C和Ctrl+V可能是開發(fā)人員使用頻率最高的按鍵組合，致使一些鍵盤不是“面目全非”就是“半身不遂”，試想一下，如果我們拿出來一鍵生成部署頁面的功能，是否能讓“久經(jīng)磨難”的鍵盤依然“歷久彌新”呢？沒錯(cuò)，這是我們接下來的目標(biāo)。

低代碼平臺(tái)的模板是指根據(jù)長期積累的經(jīng)驗(yàn)，總結(jié)一些具有共性的通用方案，并且提煉成所有用戶都能直接使用的頁面或應(yīng)用，收錄到模板庫中，當(dāng)平臺(tái)上的其他用戶需要使用類似應(yīng)用或頁面時(shí)，只需要找到合適的模板，一鍵即可生成頁面或應(yīng)用，甚至能拿來即可用，無需做任何修改。后期可以允許建立團(tuán)隊(duì)自己的模板庫，各成員可以搭建自己的模板專門供團(tuán)隊(duì)使用。