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

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

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

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

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

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

次の両方について説明します グローバルリファレンスアーキテクチャ(GRA) およびシングルインスタンスのインストール。

定義

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

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

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

機能マトリックス

機能
Git
コンポーザー
メインコードリポジトリー
すべてのコードは、1 つまたは複数の Git リポジトリに格納されます
すべてのコードは、Composer リポジトリのパッケージに格納されます
各 Composer パッケージは、Git リポジトリで表されます
コードロケーション
開発は次の場所で行われます app/ directory
開発は次の場所で行われます vendor/ directory
コアアップグレード管理
Adobe Commerce Core は、Composer を使用してインストールおよびアップグレードされ、結果は Git でコミットされます
Adobe Commerce コアは、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. Composer と app/code モジュールの場合

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

    例:

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

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

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

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

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