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

Last update: Mon Nov 25 2024 00:00:00 GMT+0000 (Coordinated Universal Time)

トピック：
ベストプラクティス

作成対象：

経験者
開発者

このトピックは、リリース管理、コードの複雑さ、依存関係の管理を考慮に入れながら、カスタムコードを配布する際に 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 の統合が可能

コードに対する変更をインストールですぐに利用できる

回避するソリューション

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

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

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

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

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

recommendation-more-help

754cbbf3-3a3c-4af3-b6ce-9d34390f3a60