Adobe Commerceのコード管理のベストプラクティス
このトピックは、リリース管理、コードの複雑さ、依存関係の管理を考慮して、GitまたはComposerを使用してカスタムコードを配布するかどうかを決定するのに役立つように設計されています。
NOTE
これらのベストプラクティスは、移行と実装に最適です。単一モジュール開発には適していません。
影響を受ける製品とバージョン
- Adobe Commerce on cloud infrastructure
- Adobe Commerce オンプレミス
定義
- グローバルリファレンスアーキテクチャ（GRA）：ホワイトラベルアーキテクチャまたは共通コードベースとも呼ばれます。 これは、マルチインスタンスセットアップのモジュール配布アーキテクチャです。
- マルチインスタンス設定：同じクライアントが、地域やブランドごとに個別のAdobe Commerce インストールを使用します。 各インストールには、共有モジュールと固有のモジュールがあります。
- シングルインスタンスのセットアップ:Adobe Commerceのインストールは 1 つだけです。 異なるテスト環境に対してソースコードのコピーが複数存在する場合がありますが、実稼動コードのバージョンは 1 つのみです。
GitまたはComposerを使用する場合
主にGitを通じて管理されるコード
主にComposerを通じて管理されるコード
シングルインスタンス設定に使用する場合
- シングルインスタンス設定のコードを管理するための標準的なアプローチ
- 将来、コードベースがマルチブランド GRAに含まれない場合
- すべてのブランドがweb サイトとして単一のインスタンスで運営されている場合
- 将来、コードベースがマルチインスタンス設定の一部になれる、または一部になる場合
マルチインスタンス設定に使用する場合
- ほとんどすべてのモジュールが相互にリンクされている場合（推奨されません）
- Composerに精通していないチームがコードを保守する場合
- マルチインスタンス設定のコードを管理するための標準的なアプローチ
- Adobeでコードベースを管理する場合、またはメンテナンス部門がComposerに精通している場合
機能マトリックス
機能
Git
Composer
メインコードリポジトリ
すべてのコードは、単一または少数のGit リポジトリに格納されます
すべてのコードは、Composer リポジトリ内のパッケージに格納されます
各Composer パッケージは、Git リポジトリで表されます
各Composer パッケージは、Git リポジトリで表されます
コードの場所
開発は
app/ ディレクトリで行われます開発は
vendor/ ディレクトリで行われますコアのアップグレード管理
Adobe Commerce コアはComposerを使用してインストールおよびアップグレードされ、結果はGitでコミットされます
Adobe Commerce コアは、Composerを使用してインストールおよびアップグレードされます。結果はGitでコミットされます
サードパーティモジュールの管理
サードパーティ製モジュールがMarketplaceまたはpackagist.orgを通じてインストールされている場合は、
vendor/にインストールされます。 それ以外の場合は、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とComposerの両方のワークフローを（どちらか一方ではなく）開発チームに説明します。
app/codeに互換性のないモジュールをインストールします。このモジュールが発生するのを防ぐ場所はありません。- モジュールを
app/codeからComposerに移行する（または逆に移動する）ことは、特に継続的な開発では面倒です。
-
Satis パッケージマネージャー
プライベートパッケージスト±年間600 ユーロです。 このコストは、GRA全体を合わせたもので、ブランドあたりのコストではありません。 無料のソリューション Satisを使用して、これらのコストを回避しようとしない。 Satisは、Gitにコミットをプッシュするたびにパッケージを自動的に更新しません。 Satisには認証が組み込まれていません。 Satisを実行するには、Web サーバーを管理する必要があります。 Satisを維持するために、多数のプライベートパッケージストのサブスクリプション料金を費やすことになります。
-
Gitで始めて、Composerに移動
プロジェクトの開始時に、コード管理アプローチを選択します。 GitからComposerに切り替えたり、逆に継続的な開発を行う場合は面倒になり、コードの損失やリビジョン履歴の損失につながる可能性があります。
recommendation-more-help
commerce-operations-help-implementation-playbook