引言
在當今快速發展的軟件開發領域,低代碼平臺憑借其可視化界面和拖拽功能,極大地減少了手動編碼的工作量,顯著提高了開發效率和質量。它提供了豐富的預構建模塊、組件和服務,讓開發者能夠根據業務需求和邏輯進行組合與配置,而無需關注底層的技術細節。同時,低代碼平臺還支持與其他系統和服務的集成,以及在不同的云環境或本地環境中部署和擴展應用程序。然而,在使用低代碼平臺開發應用程序的過程中,版本管理成為了一個至關重要的問題。版本管理不僅有助于開發者記錄和保存每一個版本的變化,方便進行回溯、比較、合并和恢復,還能支持多人協作開發,避免沖突和錯誤,實現持續集成和持續交付的流程。
低代碼平臺版本管理的實現方式
模型驅動的開發方法
低代碼平臺的核心特征之一是采用模型驅動的開發方法。通過圖形化的方式,開發者可以定義應用程序的數據模型、業務邏輯、用戶界面、流程等。在這種模式下,應用程序的源代碼由模型自動生成,而非開發者手動編寫。這就意味著版本管理的主要對象是模型,而非代碼。這種方式使得版本管理更加直觀和高效,因為模型的變化更容易被追蹤和理解。例如,在一個電商應用的開發中,開發者可以通過圖形化界面定義商品的數據模型、訂單的業務邏輯等,版本管理系統會記錄這些模型的每一次修改,方便后續的回溯和比較。
基于 Git 的版本控制系
Git 作為一種分布式的版本控制系統,具有眾多強大的功能,如支持分支、標簽、合并、沖突解決、歷史查看等,并且能夠與其他開發工具和平臺進行集成。低代碼平臺通常會提供一個基于 Git 的版本控制系統,允許開發者使用自己的 Git 倉庫來管理應用程序的模型。開發者既可以使用低代碼平臺的圖形化界面,也可以通過命令行工具來執行 Git 的操作,如提交、推送、拉取、分支、合并等。以一個團隊開發的項目為例,不同的開發者可以在本地創建自己的分支進行開發,完成后將代碼推送到遠程倉庫,通過合并操作將自己的代碼集成到主分支中。這樣可以有效地避免代碼沖突,提高開發效率。
云端的協作和發布平臺
除了使用 Git 進行版本管理,低代碼平臺還提供了一個云端的協作和發布平臺。這個平臺可以讓開發者在一個統一的環境中進行項目管理、團隊協作、反饋收集、測試、部署、監控等活動。它與 Git 倉庫進行同步,確保應用程序的版本一致性和安全性。開發者可以使用這個平臺創建、管理和切換不同的應用程序版本,如開發版、測試版、生產版等,并在不同的環境中部署和運行應用程序,包括公有云、私有云、混合云、本地環境等。例如,在一個企業級應用的開發過程中,開發者可以在云端的協作和發布平臺上創建開發版進行功能開發和測試,通過測試后將其切換為生產版進行正式部署。
低代碼中版本管理的必要性
在軟件工程的早期,開發者管理的版本與最終用戶看到的軟件版本一致,這導致一個版本包含的內容過多。開發者難以針對部分內容進行回滾以快速定位問題,多人協作開發時也難以及時合并代碼進行自測,存在較大風險。隨著版本管理粒度的細化,從管理軟件版本到管理更細化的源代碼(低代碼的工程文件)版本,版本管理應運而生。在低代碼開發中啟用 “協作工程”,引入軟件工程中主流的版本管理技術,具有諸多重要意義。它可以避免硬盤文件損壞導致工程無法打開的問題,確保數據的安全性和可恢復性。同時,能夠確定與線上版本一致的工程,避免修改線上 Bug 后出現預期外的結果,保證軟件的穩定性和可靠性。
低代碼與 Git 的對比
低代碼的可視化操作 | Git 的概念和命令 | 說明 | 常見應用場景 |
---|---|---|---|
協同工程 | 本地 repository | 低代碼中的協同工程對應 Git 的本地倉庫,用于存儲和管理本地的應用程序版本 | 在新的電腦上打開現有的工程,開發者可以將遠程倉庫的文件克隆到本地,創建協同工程 |
- 協作服務器地址 | 遠程 repository(HTTPS)地址 | 協作服務器地址即遠程倉庫的地址,用于在低代碼平臺和遠程倉庫之間進行數據交互 | 創建一個工程后,將其上傳到版本管理服務器,需要指定遠程倉庫的地址 |
- 分支 | 分支 branch | 低代碼和 Git 都支持分支功能,方便開發者進行并行開發和管理不同版本的代碼 | 在開發新功能或修復 Bug 時,開發者可以創建新的分支進行開發,完成后再合并到主分支 |
- 打開工程 | 克隆 clone | 將遠程 repository 的文件拉取到本地,在低代碼中表現為打開協同工程 | 在新的電腦上打開現有的工程,通過克隆操作將遠程倉庫的文件復制到本地 |
- 創建工程 | 強制推送 push --force | 遠程 repository 的文件被廢棄,采用本地文件覆蓋,通常用于初始化遠程 repository | 創建一個新的工程并上傳到遠程倉庫時,可能需要使用強制推送操作 |
工程模塊與狀態 | 文件狀態 status | 查看變更的文件和放在緩存區(新增)的文件,低代碼中可以檢查哪些文件被鎖定以及鎖定者 | 檢查哪些文件被鎖定了,確認是誰鎖定了這些文件,避免多人同時修改導致沖突 |
- 簽出 | N/A | 低代碼自行實現的文件鎖定機制,其他開發者無法簽出已經標記為簽出的文件,修改文件時,設計器自動設置簽出狀態,用戶也可以在【工程模塊】頁面手動簽出 | 修改某個文件時,先進行簽出操作,確保只有自己可以修改該文件 |
- 簽入 | 提交并推送 commit + push | 將本地的修改提交到本地倉庫,并推送到遠程倉庫 | 完成文件的修改后,進行簽入操作,將修改保存到版本管理系統中 |
未處理的變更 | 文件狀態 status | 查看未處理的變更文件 | 檢查還有哪些文件的修改尚未提交到版本管理系統 |
提交歷史 | 日志 log | 查看遠程分支的所有提交記錄,以及每次提交中包含的全部內容 | 了解項目的開發歷史,查看每個版本的修改內容 |
- 回滾到當前選擇的版本 | 徹底回退 reset –hard | 將遠程分支徹底回退到某個版本,然后將該版本的文件拉取到本地,覆蓋本地文件 | 當發現某個版本出現問題時,可以回滾到之前的版本 |
- 當前選定的版本另存為 | 克隆 clone | 將遠程 repository 的文件拉取到本地,然后生成一個新的工程文件 | 需要保存某個特定版本的工程時,可以將其另存為一個新的工程文件 |
獲取最新版本 | 拉取 pull | 獲取遠程文件,本地修改過的文件、放在緩存區(新增)的文件都會被保留 | 在進行開發前,獲取最新的代碼,確保自己使用的是最新版本 |
- 強制同步為最新版本 | 強制拉取 pull --force | 本地文件被廢棄,使用遠程文件覆蓋 | 當本地文件出現問題或需要與遠程倉庫保持完全一致時,可以使用強制拉取操作 |
建立版本管理規則
為了確保版本管理的有效性和一致性,在開發過程中建立版本管理規則是非常必要的。以下是一些推薦的規則:
- 除非是臨時的實驗項目或學習、練習用項目,建議所有投入使用的項目都啟用版本管理。這樣可以更好地管理項目的變更歷史,提高項目的可維護性。
- 開發者需要為每一次提交的代碼寫 “簽入注釋”。詳細的簽入注釋可以幫助其他開發者了解代碼的修改內容和目的,方便后續的代碼審查和維護。
- 在簽入之前,需要先【獲取最新版本】,完成自測,確保功能無誤后再執行簽入操作。這樣可以避免將有問題的代碼提交到版本管理系統中,影響其他開發者的工作。
- 在啟用了多分支的項目中,除負責分支合并的開發者外,其他人都不允許簽入到 master 分支。這樣可以保證 master 分支的穩定性,避免因誤操作導致的代碼沖突和問題。
- 除非必要,不要手動簽出模塊或頁面,盡量減少簽入的范圍,以免影響其他人的工作。合理控制簽入范圍可以降低代碼沖突的風險,提高開發效率。
- 團隊成員間按照功能模塊或前后端的方式進行分工,可有效避免簽出時發生沖突。明確的分工可以讓開發者專注于自己負責的部分,減少代碼沖突的可能性。
- 插件、服務端引入的編程擴展類庫、前端引入的 JavaScript 文件等沒有納入設計器的版本管理,推薦在對應的開發工具(如 Visual Studio)上做好版本管理。這樣可以確保這些外部資源的版本也得到有效的管理。
多分支管理實踐
在項目發布上線后,團隊在開發新版本的同時,可能需要對舊版本的 Bug 進行快速修復。為了避免新版本開發和舊版本維護工作之間的干擾,需要引入多分支管理。以下是一個常見的多分支管理方案:
分支定義
- Master:主分支,與線上環境同步,通常不允許開發人員直接簽入。它是項目的穩定版本,代表著線上正在運行的代碼。
- Develop:新版本開發的分支,從 Master 分支上創建。在這個分支上進行新功能的開發和測試,完成后將代碼合并到 Master 分支。
- Hotfix:為修復重要 Bug 單獨創建的分支,從 Master 分支創建。當線上出現緊急 Bug 時,在這個分支上進行修復,修復完成后將代碼合并到 Master 分支和 Develop 分支。
分支操作流程
場景 | Master | Develop | Hotfix |
---|---|---|---|
立項 | 專人創建 master 分支 | 專人從 master 創建 develop 分支 | |
V1.0 的開發階段 | 所有人在 develop 分支開發 | ||
V1.0 發布 | 專人將 develop 合并到 master | ||
V2.0 的開發階段 | 所有人在 develop 分支開發 | ||
V2.0 的開發過程中,發現需要緊急修復的 Bug | 專人從 master 創建 hotfix 分支 | ||
執行 Bug 修復 | 負責修復的開發者在 hotfix 分支開發 | ||
Bug 修復版(V1.1)發布 | 專人將 hotfix 合并到 master | 負責修復的開發者參考 master 分支的做法,結合 V2.0 的功能,在 develop 分支上完成 bug 修復 | |
V2.0 發布 | 專人將 develop 合并到 master |
低代碼中協同操作步驟示例
在 Git 中復制代碼鏈接
開發者需要在 Git 倉庫中找到對應的項目,復制代碼鏈接。這個鏈接將用于在低代碼平臺中創建協同工程。例如,在 Gitee 上的項目,開發者可以在倉庫頁面找到 HTTPS 或 SSH 鏈接,點擊復制按鈕將鏈接復制到剪貼板。
在低代碼中創建協同工程
打開低代碼設計器,在上方菜單欄中選擇 “高級”,然后選擇創建工程。在彈出的對話框中,輸入協作服務器地址(即之前復制的 Git 代碼鏈接)和分支名稱,點擊 “確定”。系統會進行身份驗證,驗證通過后將當前工程推送至對應倉庫,成功創建協同工程。
對象協同化
創建協同工程后,在左側的對象管理器中,可以看到每個獨立的頁面、母版頁等都帶有一個小鎖的標志。當某個頁面或其他元素被簽出后,鎖標志會變為綠色對勾,表示該元素正在被修改。
選擇性提交未處理變更
在簽入所有未處理變更時,開發者可以選擇簽入的部分,忽略無須簽入的部分。這樣可以更加靈活地管理代碼的提交,避免不必要的代碼變更被提交到版本管理系統中。
詳細的提交歷史
提交歷史會詳細記錄每一位協同人員的簽入信息,并且支持另存為、回滾任意版本。開發者可以通過查看提交歷史了解項目的開發進度和每一次修改的內容,方便進行問題排查和版本回溯。
工程模塊
在模塊選項中,可以看到各個模塊的狀態,并會細化到低代碼設計器中的各個功能點。這有助于開發者了解項目的整體結構和各個模塊的狀態,及時發現和解決問題。
打開協同工程
低代碼平臺支持開發人員打開已有的協同工程,隨時隨地加入協作人員,共同進行項目的開發。開發者只需輸入協作服務器地址和分支名稱,即可打開對應的協同工程。
結論
低代碼平臺通過模型驅動的開發方法、基于 Git 的版本控制系統和云端的協作和發布平臺,實現了高效、安全、靈活的版本管理。版本管理在低代碼開發中具有重要的意義,它不僅可以幫助開發者記錄和保存每一個版本的變化,方便進行回溯、比較、合并和恢復,還能支持多人協作開發,避免沖突和錯誤,實現持續集成和持續交付的流程。通過建立合理的版本管理規則和采用多分支管理實踐,可以進一步提高開發效率和項目的穩定性。同時,低代碼平臺提供的協同操作步驟使得團隊協作更加便捷和高效。隨著低代碼技術的不斷發展,版本管理將在軟件開發中發揮越來越重要的作用,幫助企業更快地交付高質量的應用程序。
活字格低代碼開發平臺