Magento / Composer / Deploymentの管理

そのため、私はハッカソンのMagento Composerインストーラーの使用を楽しんでいますが、展開サービスに関連して他のユーザーがどのように使用するかを理解するのに苦労しています。現在、DeployHQを使用しています。はい、レポジトリの更新がある場合にcomposerをデプロイおよび実行するように設定できますが、これは今のところ意味がありません。

ビルドに含めるすべてのパッケージのjsonファイルのみを含むメインのコンポーザーリポジトリは、新しいパッケージをリストに追加したときにのみ更新されます。

テーマまたはカスタム拡張（jsonファイルで参照されている）を更新するとき、展開サービスを更新するための「フック」はありません。そのため、サーバーにログインして手動でcomposerを実行する必要があります（終了するまでサイトを停止します）。

他の人はこれをどのように管理していますか？composerをローカルでのみ実行し、ベンダーフォルダーをレポに含める必要がありますか？

どんな答えでも大歓迎です。

Composerを使用してすべてのMagentoサイトを展開できる構造を代理店に設定しました。これは、あなたが尋ねた質問には少しやり過ぎかもしれませんが、とにかく構造の基本的な概要は次のとおりです。

リポジトリ構造

以下は、「親」リポジトリのフォルダ構造です。これには、コンポーザーJSONとロックファイル、および展開に必要なその他の構成が含まれています。

- code
   - magento
- deployment
- environmental
   - local
       - local.xml
       - robots.txt
   - staging
       - local.xml
       - robots.txt
   - production
       - local.xml
       - robots.txt
- provisioning
- public
   - index.php
- vendor
- composer.json
- composer.lock

• すべてのクライアント固有のカスタマイズは、Composerを使用してインストールされる個別の「カスタマイズ」モジュールに保存されます
• MagentoコアはGitサブモジュールとして含まれています（code/magento）
• カスタムindex.phpおよびメディアやエラーなどの他のフォルダーは、Magentoルート外のパブリックフォルダー内にあります
• 環境固有のファイル（local.xml、robots.txtなど）は、展開プロセス中にMagentoルートにシンボリックリンクされます
• ベンダーフォルダーはGitから除外されていますが、composer.lockファイルは含まれています。

展開

• 複数のアプリサーバーと環境（ステージング/実稼働）を可能にするCapsitranoを使用して展開します
• Capistranoはサーバー上のコードベース全体を新しいフォルダーに構築し、最後にwebrootシンボリックリンクを交換します。つまり、Webサイトのダウンタイムはありません。
• Capistrano composer installはビルド中に実行され、すべてのモジュールをMagentoサブモジュールにデプロイします。

これはまだ継続的なインテグレーションのセットアップではありませんが、Magentoのサイトではうまく機能していると思います。セットアップに固有のアドバイスが必要な場合は、お気軽にメッセージをお送りください。

もう1つの方法は、magentoハッカソンコピーデプロイ戦略を使用することです。これは、composer.jsonファイルで次のようになります。

"extra": {
    "magento-root-dir": "./",
    "magento-deploystrategy": "copy",
    "magento-force": true
}

上記の方法を使用すると、インストールされたファイルがベンダーから実際のインストールにコピーされるため、Gitでコミットし、コンポーザーのインストールを行わずに通常どおりに展開できます。

ライブ展開をしようとしているときにサードパーティのリポジトリからプルすることは大したファンではありませんし、ネットワークのプロキシキャッシュのようなものがない限り、サードパーティのリポジトリに依存することはちょっと危険です。

この記事を読むと、別の視点が得られます：http : //www.letscodejavascript.com/v3/blog/2014/03/the_npm_debacle

基本的に、NPMはダウンして（ある種の..）、NPMに直接依存していたため、すべてのビルドシステムが動作しなくなりました（重要な展開のため！）。（NPMはPackagist for Javascriptに似ていますが、NPMは実際にファイルをホストし、PackagistはモジュールのGithubリポジトリを指しているだけです。間違っている場合は修正してください）

編集：ちょうど赤いfschmenglerの応答..これは彼の最初のアプローチの詳細

Composerは展開ツールではなく、開発ツールであることを理解することが重要です。

すべての依存関係を使用して展開を準備する方法はさまざまです。

• ベンダーディレクトリ（またはComposerがソースをインストールする場所）をプロジェクトリポジトリにコミットする
• 実行composer installして結果を含むアーカイブを作成するビルドサーバーを使用します。これは、異なるターゲットシステムに繰り返し可能にデプロイできます
  • composer installサーバー上で実行し、@ jharrison.auが示唆するようにシンボリックリンクを切り替える

それはさておき、私はすべてのモジュールにコンポーザーを使用することはお勧めせず 、プロジェクトリポジトリにのみ保存 composer.jsonしcomposer.lockます。これは無理があり、開発が不必要に複雑になります。複数のプロジェクトで再利用されるコードには最適ですが、プロジェクト固有のコードを別のリポジトリに配置するのはなぜですか？

私の現在のプロジェクト構造は次のようになっています（AOEの代替の作曲家インストーラーを使用）：

• srcすべてのプロジェクト固有のモジュールが含まれています。Composerは、他のMagentoモジュールもここにインストールします
• .modmansrcmodmanがシンボリックリンクを簡単に処理できるようにリンクします
• wwwはwebrootです。Composerは、Magentoコアをここにインストールします

この方法で、リポジトリに外部モジュールを含めます。そうしたくない場合は、次のように調整します。

• srcすべてのプロジェクト固有のモジュールが含まれています。.modmanmodmanがシンボリックリンクを作成するようにそれらを含めるには、以下を使用しますmodman link
• .modmanにあり.gitignoreます。ComposerはここにMagentoモジュールをインストールします
• wwwはwebrootです。Composerは、Magentoコアをここにインストールします