Home > PHP > composer install をどこで実行するか

composer install をどこで実行するか

  • 2014-03-06 (木) 11:00
  • PHP
この記事の所要時間: 32

最近の PHPer が集まれば、一度は話題に上がるのが、この composer install をどこで実行するのか問題。

Composer

これまで聞いた話をまとめると、大きく分けて、以下の2パターンになります。どちらの方法を取っているか教えて下さい 😀

0. 前提

前提ですが、以下のような方法で、Composer 関連のファイルは管理しているとします。おそらく多くはこのような形になっていると思います。

  • PHP コードは、Git などの VCS で管理する。
  • composer.json, composer.lock は、VCS で管理する。
  • composer.phar, vendor/ は、VCS で管理しない。

また、今回対象としているのはアプリケーションで、Packagist に登録して、配布するようなフレームワークやライブラリは対象外です。

1. 本番サーバで実行

本番PHPサーバ上で composer install を実行するパターンです。

本番PHPサーバに何かしらの方法で、PHP コードと共にcomposer.jsoncomposer.lockを設置し、composer installを実行します。

複数台サーバがある場合、それぞれのサーバで実行します。

コマンドの実行は、SSH でログインして手でする人もいるでしょうし、CapistranoやFabricなどで、自動化している人もいます。

順番としては、PHPコードをデプロイしてから、依存解決(composer install)になります。

2. 別サーバで実行して、実行結果を本番サーバに設置

本番PHPサーバ以外の場所で、composer installを実行して、生成されたvendor/を本番サーバに設置する方法です。

composer installを実行する場所は、ビルドサーバの場合もありますし、開発者の PC の場合もあります。

本番サーバではcomposer installを実行しないのがポイントです。

こちらは、依存解決してからデプロイの順になります。

私の場合

私自身は、本番環境については、2. の方法で行っています。

依存解決は、デプロイの前に行っておき、すでに依存解決されたものを本番環境にデプロイします。

The Twelve-Factor App で言うところのビルドステージで行うものという認識です。

ビルドステージ は、コードリポジトリを ビルド と呼ばれる実行可能な塊へと変える変換である。デプロイプロセスで指定したコミットのコードで指定されたバージョンを使って、ビルドステージは依存関係を取得してローカル環境に配置し、バイナリやアセットファイルをコンパイルする。

ビルドステージで可変部分は全て処理しておき、本番環境には、イミュータブルなパッケージとしてデプロイします。(実際は、パーミッションの設定など多少の操作は必要ですが)

複数台の場合、あちこちでcomposer installを実行するのが単純に無駄というのもありますし、大きな可変部分を各サーバで実行するより、1箇所で生成して、全く同じものを各サーバに配布した方が安全かと。

ただ、1. の方が手軽なので、こちらを採用しているという意見も良く聞きますね。

さいごに

Composer が普及してきたからこそ出てくる議論だと思うので、すっかり利用するのが当たり前になりましたね。今後は、こうした運用面に関するノウハウも共有していきたいです。

上記案に限らず、こうしてるよ、などあれば教えて下さい。

Pocket

follow us in feedly

Home > PHP > composer install をどこで実行するか

検索
フィード
メタ情報

Return to page top