手軽にCIを体験してみたい・その2

Proactive Web Performance Optimization with Jenkins

前回の記事が全然手軽じゃない気がしてきたので、今回も幾分かマシにCIを体験するというかCIサーバ立てずにがんばってみる。

Jenkins・WPT・GitHub

前回はTravisとYSlowを使ってパフォーマンステストをしたけど、今回はJenkinsとWebPagetestを使って全く同じことをしてみる。

やっぱしTravisの設定が慣れないんだなぁ。ちなみに普通のユニットテストとかだったら、アクセストークンとか必要ないのでもっと簡単にできる。僕はGruntプラグインの開発で使用している。

例えば、grunt-cssoの設定は上記みたいな感じ。ymlは実行環境指定してあるだけだし、package.jsonはgrunt testのコマンドを実行してるだけで、要はnodeunitテストだ。ローカルでやるのとたいして変わらない。

なので、おもしろくない。

Jenkins

やっぱり私、Jenkins触りたいんですですおおおお＾q＾！ってことで、世の中にはクラウドサービスとしてJenkinsを使えるそうで、CloudBeesってとこのDEV@cloud使ってみる。便利な世の中だ。

Freeでは月300分までのビルドまでしかできなかったり制限あるけど、ちょっとJenkinsに触りたいんです欲求ぐらいなら満たせる。

Jenkinsシステム設定

まず、GitHubとJenkinsの連携だけどDEV@cloudのJenkinsはGit Pluginがデフォルトでインストールしてあるのでこちらでインストールしなくてもいいので楽です。

CloudBees DEV@cloud AuthorizationでCloudBees Public KeyをGitHubのAccount SettingsのSSH Keysに登録しておく。

NodeJS

次に後述するWebPagetest(WPT)をNode.jsから利用するのでJenkinsにNode.jsをインストールしたい。NodeJS Pluginを検索してインストールすれば、Jenkinsのシステム設定からNode.jsをバージョン管理できるようになる。

またwebpagetestパッケージが必要なので、Global npm packages to installからインストールできるようにしておく。

Jenkinsビルド設定

新規ジョブ作成から『フリースタイル・プロジェクトのビルド』を選択する。

ソースコード管理システムはGitを選択しレポジトリURLを設定する。ここではgit@github.com:t32k/maple.gitを指定。

SCMをポーリング

次はビルド・トリガで、『SCMをポーリング』にチェックを入れ、スケジュールには本来Cronの設定を書くが今回はGitHubのServer Hookをトリガとするので、何も入力しない（便宜上、チェックをいれるらしい）。

Service Hooks

GitHubのMapleのSettingsからService Hooksで、Jenkins (Git plugin)を選択肢、Jenkins Urlを入力し、Activeにする。これでGitフックの設定は終わり。MapeレポジトリにコミットするとJenkinsがビルドする。

ほかにもいろいろ方法があるらしいので下記ページを参照してほしい。

次はビルド環境で、Provide Node & npm bin/ folder to PATHにチェックをする。

ビルドには『シェルの実行』を選択し、下記のようなコマンドを設定。

git checkout gh-pages
git rebase origin/master
git push origin gh-pages
git checkout master
test/test.sh YOUR_PRIVATE_INSTANCE_URL

要はmasterの内容をgh-pagesのブランチにマージしてWebPagetestを走らせているのだ。このへんはシェルでどうにでもできるので使い勝手がいい。

JUnitテスト結果の集計

で最後に、ビルド後の処理としてJUnitテスト結果の集計を選択して、WebPagetestのテスト結果XMLのファイル名を選択すれば、Jenkinsのひと通りの設定は終わりだ。

WebPagetest

WebPagetestはこのブログでも何回か紹介しているが、Webパフォーマンスの計測サービスだ。それをNode.jsのラッパーでCLIからテストを実行できるようにしたのがwebpagetest-api。

これを利用するには自分でプライベートインスタンスを作ってそこでテストを実行させるか、パブリックインスタンス上でテストを実行させるかの2つだけど、後者はWPTの作者にメールしてAPIキーをもらわなきゃいけない。

もうこの辺りから全然お手軽でもないんだけども、プライベートインスタンスとか立ち上げるのだるいし（弊社にはあるのでウェーイ♪、今回の例ではAPIキーを利用していない）、とりあえず、Please API Key!ってメール投げてみましょう。1日200回までなら実行可能っぽいす。

とりま、このラッパーを使って上記のようなコマンドをシェルファイルとして実行している。今回は--server $1でプライベートインスタンスのURLを指定しているけど、みなさんは代わりに--key $1でAPIキーを引数でとるようにしてもらえればよいかと思います。

--poll 3は、WPTのテストを実行しただけでは結果がかえってくるまで時間がかかるので3秒ごとにポーリングして結果が帰ってくるまで待ってるって意味。

--specs test/spec.jsonにはどの項目がどの程度のパフォーマンスまで許容できるのかしきい値を書いておく。

MapleのスペックではfistViewでリクエストが50、renderタイムが5000ms、loadTimeが10000msを超えるようであれば失敗とみなしている。ここら辺りは今はちょっと適当にやってるのだけど、YSlowに比べていろんな指標をWPTではチェックできるのでこんな風にしてスペック書くんだよってことを理解してもらえればよいです。

reporter xunit > webpagetest.xml 最後はXML形式でテスト結果を保存するよーって意味です。これをJenkinsに読み取らせて、Jenkins上でテスト結果が確認できるのです。

細かな設定に関してはここをみるとよいです。

ほんとは、TAP形式のレポートのほうが見やすくて良いのだけど、CloudBeesのJenkinsにはTAPレポートを表示させるJenkinsプラグインがインストール出来ないからJUnit形式にしている。

テスト結果

で、適当になんかPushしてやると、Jenkinsたんがビルドを走らせて上記のような結果を頂けます。

んなわけでやっぱJenkinsでこれだけいろいろできるのはよいなーと思いました。