Composerの開発/本番スイッチを使用する場合、正しくデプロイする方法は？
Composerには、開発中にのみいくつかの依存関係をロードするオプションがあるため、ツールは運用環境（ライブサーバー）にインストールされません。これは、（理論的には）テスト、fake-data-tools、デバッガーなどの開発でのみ意味のあるスクリプトに非常に便利です。
方法は、devで必要なツールを使用してrequire-devブロックを追加することです。
"require-dev": {
"codeception/codeception": "1.6.0.3"
}
そして、（理論的に）これらの依存関係を次の方法でロードします
composer install --dev
問題と質問：
Composerは2013年にinstallとupdateの動作を劇的に変更し、require-dev-依存関係がデフォルトでインストールされるようになりました（！）。require-devブロックし、composer installを実行して再現します。
最も受け入れられているデプロイ方法は、composer。lock（現在のcomposerセットアップを保持）をプッシュしてから、プロダクションでcomposer installを実行することです。サーバーの場合、これも開発用のものをインストールします。
これを展開する正しい方法は何ですか-dev依存関係をインストールせずに？
注：ここでは、奇妙なComposer展開を明確にするために、標準的なQ/Aを作成しようとしています。この質問は自由に編集してください。
なぜ
最近ではComposerがデフォルトで--devフラグを使用する（インストール時および更新）理由は、私見にはあります。作曲家はこれが望ましい振舞いであるシナリオの大部分で動かされます：
基本的なComposerのワークフローは次のとおりです。
- 新しいプロジェクトが開始されます。
composer.phar install --dev、json、およびロックファイルがVCSにコミットされます。 - 他の開発者がプロジェクトに取り組み始めました：VCSと
composer.phar install --devのチェックアウト。 composer.phar require <package>セクションにパッケージを追加したい場合は、開発者が依存関係を追加します：--dev、require-devを追加します（そしてコミットします）。- 他の人は一緒に行きます：（checkoutと）
composer.phar install --dev。 - 開発者は、より新しいバージョンの依存関係が必要です：
composer.phar update --dev <package>（およびcommit）。 - 他の人は一緒に行きます：（checkoutと）
composer.phar install --dev。 - プロジェクトがデプロイされています：
composer.phar install --no-dev
ご覧のとおり、--devフラグは--no-devフラグより（はるかに）多く使用されています。特に、プロジェクトに取り組んでいる開発者の数が増えている場合は特にそうです。
本番デプロイ
"dev"依存関係をインストールせずにこれをデプロイする正しい方法は何ですか？
composer.jsonおよびcomposer.lockファイルはVCSにコミットする必要があります。使用すべきパッケージバージョンに関する重要な情報が含まれているため、composer.lockを省略しないでください。
プロダクションデプロイを実行するときは、--no-devフラグをComposerに渡すことができます。
composer.phar install --no-dev
composer.lockファイルには、dev-packagesに関する情報が含まれている場合があります。これは関係ありません。 --no-devフラグはそれらのdev-packagesがインストールされていないことを確認します。
「プロダクションデプロイ」と言うとき、プロダクションで使用されることを目的としたデプロイを意味します。私はcomposer.phar installをプロダクションサーバー上で行うべきか、それとも物事をレビューできるステージングサーバー上で行うべきかについて議論していません。それはこの答えの範囲ではありません。私は単に "dev"依存関係をインストールせずにcomposer.phar installを実行する方法を指摘しているだけです。
オフトピック
--optimize-autoloaderフラグはプロダクション上でも望ましいかもしれません（それはあなたのアプリケーションでオートロードをスピードアップするクラスマップを生成します）：
composer.phar install --no-dev --optimize-autoloader
自動展開が完了したとき
composer.phar install --no-ansi --no-dev --no-interaction --no-progress --no-scripts --optimize-autoloader
実際には、本番サーバーに依存関係をインストールしないことを強くお勧めします。
私のお勧めは、デプロイメントマシンでコードをチェックアウトし、必要に応じて依存関係をインストールし（コードが本番環境に移行する場合はdev依存関係をインストールしないことを含みます）、そしてすべてのファイルをターゲットマシンに移動することです。
どうして？
- 共有ホスティングでは、コマンドラインにアクセスできない場合があります。
- たとえあなたがそうしたとしても、PHPはコマンド、メモリまたはネットワークアクセスの点でそこに制限されるかもしれません
- リポジトリのCLIツール（Git、Svn）はインストールされない可能性があります。ロックファイルがZipとしてコミットをダウンロードする代わりに特定のコミットをチェックアウトするための依存関係を記録している場合は失敗します。そのバージョンを入手する他の方法はありません）
- 実稼働マシンが小規模なテストサーバー（Amazon EC2マイクロインスタンスだと思う）のようなものであれば、おそらく
composer installを実行するのに十分なメモリさえインストールされていないでしょう。 - 作曲家は物事を壊さないようにしていますが、作曲家のインストール段階ではランダムな依存関係を読み込むことができなかったため、部分的に壊れた本番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オプションが必要です。そうでなければ、作曲家は "ロックファイルにrequire-dev情報が含まれていません"と言うでしょう。
composer install --no-dev
注： devとproductionの間に違いが生じる可能性があるものには注意してください。 devツールを含めることは大きなオーバーヘッドではないので、私は一般に可能な限りrequire-devを避けようとします。
プロセスを自動化した方が良いと思います。
Gitリポジトリにcomposer.lockファイルを追加します。リリース時にはcomposer.phar install --no-devを使用してください。あなたが気にせずに任意のcomposerコマンドを使用することができるマシン、これは生産に行きません、生産はロックファイルでその依存関係をベースにします。
サーバーでこの特定のバージョンまたはラベルをチェックアウトし、テストに合格した場合はアプリを置き換える前にすべてのテストを実行し、展開を続行します。
テストがdevの依存関係に依存している場合、composerにテストスコープの依存関係がないため、devの依存関係を使用してテストを実行することはできません（composer.phar install）、ベンダーライブラリを削除し、composer.phar install --no-devを再度実行すると、キャッシュされた依存関係が使用されるため、高速になります。 。しかし、他のビルドツールのスコープの概念を知っていれば、それはハックです。
これを自動化して、残りを忘れて、ビールを飲みに行きなさい:-)
シモンズ：以下の@Svenコメントのように、composer.lockファイルをチェックアウトしないことはお勧めできません。これは、composer installをcomposer updateとして機能させるためです。
この自動化は http://deployer.org/ で行えます。これは簡単なツールです。
本番サーバーではvendorの名前をvendor-<datetime>に変更しました。デプロイ時には2つのベンダーディレクトリがあります。
HTTP cookieによって私のシステムは新しいベンダautoload.phpを選択します。そしてテストした後、将来のすべての要求に対して古いアトミックディレクトリを無効にするために完全にアトミック/インスタントの切り替えを行い、数日後に前のディレクトリを削除します。
これは私がApache/phpで使っているファイルシステムキャッシュによって引き起こされるどんな問題も避け、そしてどんなアクティブなPHPコードも以前のベンダディレクトリを使い続けることを可能にします。
他の回答では推奨されていますが、私は個人的にcomposer installをサーバー上で実行しています。これは私のステージング領域からのrsync（ラップトップ上のVM）より速いからです。
私は--no-dev --no-scripts --optimize-autoloaderを使います。あなたの環境でこれが適切かどうかをチェックするためにそれぞれのドキュメントを読むべきです。