「そんなself-updateで大丈夫か？」 Composer編 - CARTA TECH BLOG
こんにちはこんにちは、 VOYAGE GROUPでBuild prayer*1として活動している@_nishigoriです。 pip, bundler, rebar 等 各プログラミング言語のビルドツールないしパッケージマネージャ等と呼ばれているツールを弊社でも利用していますが、 PHPでは依存管理ツールとしてComposerを利用しているプロジェクトがあります。 今回はComposer本体のバージョニングについて紹介し、 利用する上での良い側面と悪い（と思われる）側面を紹介します。 はじめに Composerの入手 最新版 *2 Installer self-update リリースサイクル 効能 デメリット self-updateする日時によってrevisionが異なる（場合がある） ある日のself-updateで突然死 Tagging Versions Installer self-
composer 導入をまじめに考える - Qiita
これは結構大きいPHPのプロジェクトに composer を導入する機会があったので、そのときに考えてたことや行ったこと、使い方などをメモするために書いた。 モチベーション 私達は PHP のパッケージの管理を管理する際は pear と git submodule を利用していた。これらのやり方は意外と長続きした。これらにはついて様々な問題を抱えており、ついに限界がきてしまった。 pear pear でパッケージを導入するには root 権限が必要なので、毎回インフラチームに導入を依頼するのが必要があった。 pear で導入されたパッケージについてバージョンを上げようとすると、全APサーバーで更新をかける必要があった。 これらの点から面倒だったのと、気軽に変更できないので、不要になったものも削除されることなく、放置されるのが問題だった git submodule こちらは pear とは異
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
