Composerの開発/本番スイッチを使用するときに正しくデプロイする方法は？

Composerには、開発中にのみいくつかの依存関係をロードするオプションがあるため、ツールは本番環境（ライブサーバー上）にインストールされません。これは、（理論的には）テスト、fake-data-tools、デバッガなど、開発でのみ意味のあるスクリプトに非常に便利です。

進む方法はrequire-dev、devで必要なツールを使用してブロックを追加することです。

"require-dev": {
    "codeception/codeception": "1.6.0.3"
}

そして（理論的には）これらの依存関係を介してロードします

composer install --dev

問題と質問：

作曲はの振る舞いを変更したinstallとupdate劇的に2013年に、require-dev-dependenciesは現在デフォルトでインストールされている（！）、とcomposer.jsonを作成すること自由に感じrequire-devブロックと実行composer installに再現します。

デプロイする最も受け入れられている方法として、コンポーザーをプッシュすることです。ロック（現在のcomposer設定を保持）composer installしてから本番サーバーでを実行すると、開発コンポーネントもインストールされます。

-dev依存関係をインストールせずにこれをデプロイする正しい方法は何ですか？

_{注：ここでは、奇妙なComposerデプロイメントを明確にするために、標準的なQ / Aを作成しようとしています。この質問は自由に編集してください。}

なぜ

今日、Composerが--devデフォルトで（インストールおよび更新時に）フラグを使用する正当な理由があります。Composerは主に、これが望ましい動作であるシナリオで実行されます。

基本的なComposerワークフローは次のとおりです。

• 新しいプロジェクトが開始されます：composer.phar install --devjsonおよびロックファイルがVCSにコミットされます。
• 他の開発者がプロ​​ジェクトの作業を開始します：VCSおよびのチェックアウトcomposer.phar install --dev。
• 開発者は依存関係composer.phar require <package>を追加し--devますrequire-dev。セクションにパッケージが必要な場合は追加し、コミットします。
• 他の人は一緒に行きます：（チェックアウトと）composer.phar install --dev。
• 開発者は、依存関係の新しいバージョンcomposer.phar update --dev <package>（およびコミット）を必要としています。
• 他の人は一緒に行きます：（チェックアウトと）composer.phar install --dev。
• プロジェクトがデプロイされました： composer.phar install --no-dev

ご覧のとおり、特にプロジェクトに取り組んでいる開発者の数が--dev増えると、フラグは（はるかに）--no-devフラグよりも多く使用されます。

本番デプロイ

「dev」依存関係をインストールせずにこれを展開する正しい方法は何ですか？

まあ、composer.jsonand composer.lockファイルはVCSにコミットする必要があります。composer.lock使用すべきパッケージのバージョンに関する重要な情報が含まれているため、省略しないでください。

本番デプロイを実行するときに、--no-devフラグをComposerに渡すことができます。

composer.phar install --no-dev

このcomposer.lockファイルには、dev-packagesに関する情報が含まれている場合があります。これは問題ではありません。--no-devフラグは、必ずこれらのDEV-のパッケージがインストールされていないようになります。

「プロダクションデプロイ」とは、プロダクションでの使用を目的としたデプロイを意味します。私はcomposer.phar install、運用サーバーで行うべきか、レビューが可能なステージングサーバーで行うべきかについては議論していません。それはこの回答の範囲ではありません。composer.phar install「dev」の依存関係をインストールしない方法を指摘しているだけです。

オフトピック

--optimize-autoloaderフラグはまた、生産上望ましいかもしれない（それはあなたのアプリケーションに自動読み込みスピードアップするクラスマップを生成します）：

composer.phar install --no-dev --optimize-autoloader

または、自動デプロイメントが行われたとき：

composer.phar install --no-ansi --no-dev --no-interaction --no-plugins --no-progress --no-scripts --no-suggest --optimize-autoloader

あなたのコードベースがそれをサポートしている場合は、スワップ・アウト可能性--optimize-autoloaderのために--classmap-authoritative。詳細はこちら

実際、本番サーバーに依存関係をインストールすることを強くお勧めします。

私の推奨は、デプロイメントマシンでコードをチェックアウトし、必要に応じて依存関係をインストールし（これには、コードが本番環境に移行する場合、開発依存関係をインストールしないことも含まれます）、すべてのファイルをターゲットマシンに移動します。

どうして？

• 共有ホスティングでは、コマンドラインにアクセスできない場合があります
• あなたがそうしたとしても、PHPはコマンド、メモリ、ネットワークアクセスの点で制限されているかもしれません
• リポジトリCLIツール（Git、Svn）はインストールされない可能性が高く、ロックファイルが特定のコミットをチェックアウトする依存関係をZIPとしてダウンロードする代わりに記録した場合に失敗します（--prefer-sourceを使用したか、Composerが持っていました）そのバージョンを取得する他の方法はありません）
• プロダクションマシンが小さなテストサーバーのような場合（Amazon EC2マイクロインスタンスを考えてください）、実行するのに十分なメモリがインストールされていない可能性があります composer install
• composerは物事を壊さないようにしていますが、Composersのインストールフェーズ中にランダムな依存関係をロードできなかったため、部分的に壊れたプロダクションWebサイトで終了することについてどう思いますか

簡単に言うと、制御できる環境でComposerを使用します。Composerを操作するために必要なものがすべて揃っているので、開発マシンは適格です。

-dev依存関係をインストールせずにこれをデプロイする正しい方法は何ですか？

使用するコマンドは

composer install --no-dev

これは、本番サーバー自体、デプロイメントマシン、または実際のソフトウェアで開発要件が誤って使用されていないかどうかを確認するための最後のチェックを行うはずの開発マシンなど、あらゆる環境で機能します。

このコマンドは、composer.lockファイルで宣言されているdev要件をインストールまたはアクティブにアンインストールしません。

開発ソフトウェアコンポーネントを本番サーバーにデプロイしてもかまわない場合は、実行composer installしても同じ処理が行われますが、移動するバイト数が増えるだけでなく、大きなオートローダー宣言も作成されます。

今、require-devあなたが行うことができますローカルの開発のために、デフォルトで有効になっているcomposer installとcomposer updateせずに--devオプション。

本番環境にデプロイする場合は、composer.lockからのパッケージがないことを確認する必要がありますrequire-dev。

あなたはこれを行うことができます

composer update --no-dev

を使用してローカルでテストし--no-devたら、すべてを本番環境にデプロイし、に基づいてインストールできますcomposer.lock。--no-devここでもう一度オプションが必要です。そうしないと、composerは「ロックファイルにはrequire-dev情報が含まれていません」と表示されます。

composer install --no-dev

注：開発と本番に違いが生じる可能性があるものには注意してください。開発ツールを含めることは大きなオーバーヘッドではないため、私は通常、可能な限りrequire-devを回避しようとします。

運用サーバーではに名前を変更vendorしvendor-<datetime>、展開中に2つのベンダーディレクトリが存在します。

HTTP cookieが原因でシステムが新しいベンダーを選択する autoload.phpテスト後、それらの間で完全なアトミック/インスタントスイッチを実行して、将来のすべての要求に対して古いベンダーディレクトリを無効にし、数日後に以前のディレクトリを削除します。

これにより、私がapache / phpで使用しているファイルシステムキャッシュによって引き起こされる問題が回避され、アクティブなPHPコードが以前のベンダーディレクトリを引き続き使用できるようになります。

他の回答はそれをお勧めしませんが、私は個人的に composer installれていませんが、ステージング領域（ラップトップ上のVM）からのrsyncよりも高速なので、にサーバーでします。

使用します--no-dev --no-scripts --optimize-autoloader。それぞれのドキュメントを読んで、これが環境に適しているかどうかを確認してください。

プロセスを自動化した方が良いと思います：

gitリポジトリにcomposer.lockファイルを追加し、リリース時にcomposer.phar install --no-devを使用していることを確認してください。ただし、devマシンでは、心配せずにcomposerコマンドを使用できます。これは本番環境に移行しません。本番環境では、依存関係はロックファイルに基づいています。

サーバーでこの特定のバージョンまたはラベルをチェックアウトし、アプリを置き換える前にすべてのテストを実行します。テストに合格した場合は、展開を続行します。

テストがdevの依存関係に依存している場合、composerにはテストスコープの依存関係がないため、devの依存関係（composer.phar install）でテストを実行し、ベンダーライブラリを削除してcomposer.phar installを実行する- -no-dev再び、これはキャッシュされた依存関係を使用するため、より高速です。しかし、他のビルドツールのスコープの概念を知っていれば、それはハックです。

これを自動化して残りを忘れて、ビールを飲みに行きましょう:-)

PS .: @Svenのコメントのように、composer.lockファイルをチェックアウトしないことはお勧めしません。これにより、composerのインストールがcomposerの更新として機能するようになります。

この自動化はhttp://deployer.org/を使用して行うことができます。これはシンプルなツールです。