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

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

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

影響を受ける製品およびバージョン

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

  • Adobe Commerce an cloud infrastructure
  • Adobe Commerceオンプレミス

両方をカバーしています。 グローバルリファレンスアーキテクチャ (GRA) および単一インスタンスのインストール

定義

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

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

主に Git で管理されるコード
主に Composer で管理されるコード
シングルインスタンスの設定に使用するタイミング
  • シングルインスタンス設定用のコード管理の標準的なアプローチ
  • コードベースが将来、マルチブランド GRA に含まれなくなる場合
  • すべてのブランドが Web サイトとして 1 つのインスタンスで実行される場合
  • 将来、コードベースがマルチインスタンス設定に含まれる、または含まれるようになる場合
マルチインスタンス設定に使用する場合
  • ほとんどすべてのモジュールが相互にリンクされている場合(非推奨)
  • コードが、コンポーザーに詳しくないチームによって管理される場合。
  • マルチインスタンス設定用のコード管理の標準的なアプローチ
  • Adobeがコードベースを管理している場合や、保守チームが Composer に詳しい場合

機能マトリックス

機能
Git
コンポーザー
メインコードリポジトリ
すべてのコードは 1 つの Git リポジトリー、またはいくつかの Git リポジトリーに保管されます
すべてのコードは Composer リポジトリのパッケージ内に存在します
各 Composer パッケージは、Git リポジトリで表されます
コードの場所
開発は app/ directory
開発は vendor/ directory
コアアップグレードの管理
Adobe Commerce Core は、Composer を使用してインストールおよびアップグレードされ、結果は Git でコミットされます
Adobe Commerce Core は、Composer を使用してインストールおよびアップグレードされます。その結果は Git でコミットされます。
サードパーティモジュールの管理
サードパーティモジュールは、 vendor/ (marketplace またはpackagist.orgを通じてインストールされる場合 )。 それ以外の場合は、にインストールされます。 app/
すべてのサードパーティモジュールが vendor/ directory
リリース
放出は、次の特徴を持つ 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. コンポーザーとの組み合わせ app/code (モジュールの)

    結果として、両方のコード管理スタイルのデメリットがすべてプロジェクトで組み合わされます。 不要な複雑さ、不安定さ、柔軟性の欠如を追加します。

    例:

    • 開発チームに、Git と Composer の両方のワークフロー(どちらか 1 つのみではなく)について説明します。
    • に互換性のないモジュールをインストールする app/code それが起きるのを止める場所がないので
    • からのモジュールの移動 app/code Composer へ(または逆に)は、特に継続的な開発にとって面倒です。
  2. Satis Package Manager

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

  3. Git から始めて、Composer に移行します。

    プロジェクトの開始時に、コード管理アプローチを選択します。 Git から Composer へ、または逆に、継続的な開発が面倒で、コードの損失やリビジョン履歴の損失につながるおそれがあります。

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