Page 4
Version 1.0.0 was released on April 5, 2016
Page 7
Get Composer!
- 2016年4月5日(今月) 正式版1.0.0リリース！
- https://getcomposer.org/download/
- PHAR形式で配布されてるので、
PHP(5.3.2+)がある環境ならどこでも動作する
- Linux/OS XのみならずWindowsもサポートしてる
- Packagist, GitHub, PEARなどと連携可能
Page 8
Composer VS pear
- pearはPHP標準のパッケージ管理コマンド
- 機能の豊富さ、利用できるパッケージの数、
新鮮さのような違いはもちろんある。
能になったことが非常に重要
理者からアプリエンジニアの手に落ちてきた（身分制度の変革）
Page 12
ライブラリの依存を記述
- requireに依存するパッケージ+バージョンを記述
{"require": {"filp/whoops": "~2.1.0"},"require-dev": {"phpunit/phpunit": "^4.8"}}
- composer require --dev "phpunit/phpunit:4.8"
Page 16
Composerを使う
- 依存ライブラリはvendor/ディレクトリに入る
- プロジェクトの .gitignore で除外しておく
- Composerに依存するPHPには以下の一行を書く
require __DIR__ . '/vendor/autoload.php';
- 何度も書く必要はなく、一度だけ読み込めばいい
- Composerでインストールされたライブラリは、
include_onceする必要がない
Page 17
オートローディング
- PHPerをinclude_onceから解き放つ福音
{"autoload": {"classmap": ["./src"]},"autoload-dev": {"classmap": ["./tests"]}}
- 詳しくはWEB+DB Vol. 81に書きました(宣伝)
Page 20
Composerの配置を考える
しかしてくれない (Windowsにはしてくれる)
- 仕事の性質に配置方法には一考の余地がある
- サーバーごと
- ユーザーごと
- プロジェクトごと
Page 24
結局どれがいいの？
プロジェクトごとにcomposer.pharを置くのが一番楽じゃないかと思う
いいけど、pixivでは git commit しちゃってる
浪費は、運用の手間を考えれば甘受できるレベル
Page 25
xdebugとComposer
- xdebugが有効な環境でComposer使うと怒られる
You are running composer with xdebug enabled. This has a major impact on runtime performance. See https://getcomposer.org/xdebug
- xdebugは開発中は有用なので外したくない
- 実際遅くなるのでシェルスクリプトを噛ませたい
- composer.phar を php -n で起動できればいい
- php.iniを無効化する＝拡張が有効にならない
Page 26
Composerのラッパー
- プロジェクトローカルに置く場合…
- composer.pharを.composer.pharにリネーム
- かわりに ./composer を利用
- chmod +x ./composer で実行権限を付与
- ファイルの中身は以下の二行
#!/bin/sh php -n $(dirname $0)/.composer.phar "$@"
Page 27
環境変数
- Composerに必要なファイルはCOMPOSER_HOME
環境変数のディレクトリにインストール
(Linux/OS X) $HOME/.composer(Windows)%APPDATA%¥Composer
インストールすることも可能ではある(やったことないけど)
Page 28
Composerを導入
$HOME/local/bin/composer に配置しておくと便利
(.bash_profileや.zshenvなどでPATHを通す)
# .bash_profile/.bashrc PATH=$HOME/.composer/vendor/bin:$HOME/local/bin:$PATH# .zshenv/.zshrc path=(~/.composer/vendor/bin(N-/)~/local/bin(N-/)$path)
Page 30
Packagist
The PHP Package Repository
Page 32
http://www.modulecounts.com/
Page 33
Packagistの特徴
- GitHubなどのリポジトリと簡単に連携できる
- API連携した状態なら、git tagをつけるだけで
かんたんに新しいバージョンをリリースできる
- 有名なライブラリ／フレームワークは登録済み
- 歴史的にフレームワークはzipファイルで公開
されてきたが、現在はComposerでもインストールできる
Page 36
デプロイ、どうしてますか？
- 稼働中のサーバーに高速にコードを配置したい
- rsyncなどで愚直にファイルを配置すると、
最中のPHPファイルが書き変わっちゃって処理途中のユーザーリクエストがエラーで落ちる
デプロイを工夫しないと、やはり落ちることが
Page 37
アトミックデプロイ
状態がユーザーの目に触れないよう工夫する
- 弊社事例(rsync+デプロイスクリプト手書き)は
WEB+DB PRESS vol. 84に載ってる
- 最近はDeployer http://deployer.org/ が
いい感じにアトミックデプロイしてくれるらしい(環境に合せて検証の必要あり)
Page 38
Satis - Package Repository Generator
- https://github.com/composer/satis
- 要はプライベートなPackagistを自前運用できる
- パッケージのアーカイブを保存できるので、
もしGitHubが不通になってしまってもデプロイできない事態を避けることができる
近いところにあればデプロイ時間の短縮になる
Page 39
Satisの運用
- 必要なライブラリをsatis.jsonに列挙する
- 記法はcomposer.jsonと同じ
- "~2.1.0"記法よりは">=2.1.0"が良い
- satis.jsonとビルドスクリプトを置いた
リポジトリを用意して、毎日定時とsatis.jsonが更新されたときに新鮮なパッケージを取得
Page 40
Satisを使う場合のcomposer.json
{"repositories": [{"packagist": false},{"type": "composer","url": "http://satis.pixiv.private/"}]}
Page 42
基本
- PackagistはGitHubでログインできるので、
GitHubに上げると非常に楽
- ブラウザで https://packagist.org を開いて
説明通りに入力していくだけ
git tag 1.4.5 && git push --tags で完了
Page 45
Packagistは遠い
- GitHub/Packagistは日本から遠いところに
あるので、ネットワークコストが非常に高い
- これはSatisを置けば解決する
- Satisを用意できない／用意するまでもない
ときは、Hirakuさんという方がミラーサイトhttps://packagist.jp/を用意してくれてるので、これを使える
Page 46
Composerは遅い
- ComposerはPHPの互換性を重視してるので、
最適な実装ではない
- Hirakuさんが並列ダウンロードできるようにした
- composerを速くするプラグイン・prestissimoを作った
http://blog.tojiru.net/article/432944706.html
