Adobe Commerce的程式碼管理最佳作法
此主題旨在協助您決定是否使用Git或Composer來發佈自訂程式碼，並考量發行管理、程式碼複雜性和相依性管理。
NOTE
這些最佳實務最適合移轉和實作，但適用於單一模組開發則否。
受影響的產品和版本
所有支援的版本 之：
- 雲端基礎結構上的Adobe Commerce
- Adobe Commerce內部部署
它同時涵蓋兩者 全球參考架構(GRA) 和單一執行個體安裝。
定義
- 全球參考架構(GRA)：也稱為白色標籤架構或通用程式碼基底。 這是多執行個體設定的模組發佈架構。
- 多執行個體設定：相同使用者端針對不同地區或品牌使用不同的Adobe Commerce安裝。 每個安裝都具有共用模組和獨特模組。
- 單一執行個體設定：只有一個Adobe Commerce安裝。 不同的測試環境可能會存在原始程式碼的多個副本，但生產程式碼只有一個版本。
何時使用Git或Composer
主要透過Git管理的程式碼
主要透過撰寫器管理的程式碼
何時用於單一執行個體設定
- 用於管理單一執行個體設定的程式碼的標準方法
- 當程式碼庫未來不再屬於多品牌GRA的一部分時
- 當所有品牌作為網站在單一執行個體上執行時
- 當程式碼基底未來可以或將成為多執行個體設定的一部分時
何時用於多執行個體設定
- 當幾乎所有模組都相互連結時（不建議）
- 當計畫碼由不熟悉撰寫器的團隊維護時
- 管理多執行個體設定的程式碼的標準方法
- 當Adobe維護程式碼庫或維護團隊熟悉撰寫器時
功能矩陣
功能
Git
作曲者
主要程式碼存放庫
所有程式碼都位在單一或數個Git存放庫中
所有程式碼都位在Composer存放庫的套件中
每個單一Composer套件由Git存放庫表示
每個單一Composer套件由Git存放庫表示
程式碼位置
開發會在中進行
app/ 目錄開發會在中進行
vendor/ 目錄核心升級管理
使用Composer安裝及升級Adobe Commerce核心，結果會在Git中認可
Adobe Commerce核心已使用Composer安裝和升級；結果會提交到Git中
協力廠商模組管理
協力廠商模組安裝於中
vendor/ 可透過marketplace或packagist.org安裝。 否則，它們會安裝在中 app/所有協力廠商模組都安裝在
vendor/ 目錄發行版本
釋出的特點是
git merge 和 git pull 或 git checkout 命令釋出的特點是
composer update 和 git pull 或 git checkout 命令Git存放庫數量
少數
許多
開發複雜性
簡單
複雜
提取請求複雜性
簡單
複雜
程式碼檢閱複雜性
簡單
簡單
開發/QA/UAT環境更新複雜性
簡單
複雜
GRA支援
模組可以自動安裝外部程式庫
GRA組合中的彈性
模組相依性管理
module.xml，功能有限
composer.json
模組版本設定
需要付費服務
Git存放庫
Git存放庫、私人封裝商(每年600±元)
可能與Jira整合Bitbucket
可立即安裝的程式碼變更
要避免的解決方案
-
組合撰寫器和
app/code適用於您的模組導致這兩個程式碼管理樣式在您的專案中結合的所有缺點。 這增加了不必要的複雜性、不穩定和缺乏彈性。
例如：
- 向開發團隊說明Git和撰寫器工作流程（而非只有一個）。
- 在中安裝不相容的模組
app/code因為目前沒有任何方法可以阻止這種情況發生。 - 移動模組
app/codeto Composer （或反之）很麻煩，尤其是在持續開發的過程中。
-
Satis封裝管理員
私人包裝商每年±費600歐元。 此成本適用於整個GRA組合，而非個別品牌。 請勿使用免費解決方案Satis來避免這些成本。 每當您推送認可給Git時，Satis都不會自動更新您的套件。 此外，Satis沒有內建授權。 您必須維護網頁伺服器才能執行Satis。 您最後會花費大量的Private Packagist訂閱費用來維護Satis。
-
從Git開始，然後移至撰寫器
在專案開始時選擇程式碼管理方法。 從Git切換到Composer或反之，進行中的開發很麻煩，並可能導致程式碼遺失和修訂記錄遺失。
recommendation-more-help
754cbbf3-3a3c-4af3-b6ce-9d34390f3a60