Adobe Commerceのコード管理のベストプラクティス

このトピックは、リリース管理、コードの複雑さ、依存関係の管理を考慮に入れながら、カスタムコードを配布する際に Git を使用するか Composer を使用するかを決定するのに役立つように設計されています。

NOTE
これらのベストプラクティスは、移行および実装に最も適しています。単一モジュール開発ではそれほど適していません。

影響を受ける製品とバージョン

サポートされているすべてのバージョン:

  • クラウドインフラストラクチャー上のAdobe Commerce
  • Adobe Commerce オンプレミス

定義

  • グローバルリファレンスアーキテクチャ(GRA):ホワイトラベルアーキテクチャまたは共通コードベースとも呼ばれます。 これは、マルチインスタンスセットアップのモジュール配布アーキテクチャです。
  • マルチインスタンス設定:同じクライアントが、地域やブランドごとに個別のAdobe Commerce インストールを使用します。 各インストールには、共有モジュールと固有のモジュールがあります。
  • シングルインスタンスのセットアップ:Adobe Commerceのインストールは 1 つだけです。 異なるテスト環境に対してソースコードのコピーが複数存在する場合がありますが、実稼動コードのバージョンは 1 つのみです。

Git または Composer を使用するタイミング

主に Git を通じて管理されるコード
主に Composer で管理されるコード
単一インスタンス設定にを使用する場合
  • 単一インスタンス設定のコードを管理するための標準的なアプローチ
  • コードベースが今後マルチブランド GRA に含まれない場合
  • すべてのブランドが web サイトとして 1 つのインスタンスで実行される場合
  • コードベースが今後マルチインスタンスセットアップに含まれる可能性がある場合、または含まれる予定の場合
マルチインスタンス設定に使用する場合
  • ほぼすべてのモジュールが相互リンクされている場合(推奨しません)
  • Composer に慣れていないチームがコードを管理している場合
  • マルチインスタンス設定用のコードを管理するための標準的なアプローチ
  • Adobeがコードベースをメンテナンスするとき、またはメンテナンスチームが Composer に精通しているとき

機能マトリックス

機能
Git
コンポーザー
メインコードリポジトリー
すべてのコードは、1 つまたは複数の Git リポジトリに格納されます
すべてのコードは Composer リポジトリ内のパッケージに格納されます
各 Composer パッケージは Git リポジトリによって表されます
コードロケーション
開発は app/ ディレクトリで行われます
開発は vendor/ ディレクトリで行われます
コアアップグレード管理
Adobe Commerce Core は、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 の統合が可能
はいアイコン
はいアイコン
コードに対する変更をインストールですぐに利用できる
はいアイコン
はいアイコン

回避するソリューション

  1. モジュール用の Composer と app/code の組み合わせ

    その結果、両方のコード管理スタイルの欠点をすべて組み合わせてプロジェクトを作成することになります。 これにより、不必要な複雑さ、不安定さ、柔軟性の欠如が生じます。

    例:

    • Git ワークフローと Composer ワークフローの両方(片方だけでなく)を開発チームに説明します。
    • 互換性のないモジュールを app/code にインストールしてください。インストールを停止する場所が何もないので、
    • モジュールを app/code から Composer に(またはその逆に)移動するのは、特に開発中の場合、面倒です。
  2. Satis パッケージマネージャー

    Private Packagist は年間±600 ユーロです。 このコストは、ブランドごとではなく、GRA 全体を組み合わせたものです。 無料のソリューション Satis を使用して、これらのコストを回避しようとしないでください。 コミットを Git にプッシュするたびに、Satis がパッケージを自動的に更新することはありません。 また、Satis には組み込みの認証がありません。 Satis を実行するには、Web サーバーを管理する必要があります。 あなたは Satis を維持するプライベートパッケージストのサブスクリプション料金の多くを費やすことになります。

  3. Git から開始し、Composer に移動する

    プロジェクトの開始時に、コード管理アプローチを選択します。 Git から Composer への切り替え、またはその逆の切り替えでは、開発が進行中の場合、コードが失われたり、リビジョン履歴が失われたりする可能性があります。

recommendation-more-help
754cbbf3-3a3c-4af3-b6ce-9d34390f3a60