composer 導入をまじめに考える - Qiita
これは結構大きいPHPのプロジェクトに composer を導入する機会があったので、そのときに考えてたことや行ったこと、使い方などをメモするために書いた。 モチベーション 私達は PHP のパッケージの管理を管理する際は pear と git submodule を利用していた。これらのやり方は意外と長続きした。これらにはついて様々な問題を抱えており、ついに限界がきてしまった。 pear pear でパッケージを導入するには root 権限が必要なので、毎回インフラチームに導入を依頼するのが必要があった。 pear で導入されたパッケージについてバージョンを上げようとすると、全APサーバーで更新をかける必要があった。 これらの点から面倒だったのと、気軽に変更できないので、不要になったものも削除されることなく、放置されるのが問題だった git submodule こちらは pear とは異
composer install と composer updateの違い
まずは改めて各ファイルの役割から。 composer.lock：現在使用しているバンドルのバージョン等が管理されます。 composer.json：必要となるバンドルを記述します。 composer.pharで実行。 んで、composer install と composer updateですが、 composer install：composer.lockに書かれている各ライブラリをインストールする。 composer update：composer.jsonをもとに各ファイルを最新版にアップデートする。 ということでした。 ユースケースとしては 新しい環境ではじめにインストールするとき：composer install 何か新しいバンドルを追加したい：composer.jsonにかいてcomposer update 本番のライブラリを最新版にしたい：開発環境でcomposer upd
いまさらComposer
PHPデプロイツールがどういう動作でタスクを処理するのか、 それぞれのデプロイツールがどんな並列処理を行うかにフォーカスを当てたスライドです。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
応用インストール - 2.x
