手軽にCIを体験してみたい

Proactive Web Performance Optimization with Travis-CI

昨年のFrontrend/06では、全くもってながら個人的な趣向のもと継続インテグレーション（CI:Continuous Integration）をテーマに開催した。もはや、フロントエンドとは！という感じだが、非常に良いイベントだったと思う。

基本的に昨今のフロントエンドは膨大なタスクに追われている、そのようなタスクを手動でちまちまやっていては手戻りやミスなど必ず発生するので自動化すべきである。フロントエンドの自動化はGruntなどがあるが、結局フロントだけで問題を解決しようとすると問題（限界）があったりするので、CIサーバーとか使ったほうがいいよね。てかフロントエンドの人も慣れておいたほうがいいよねって話。

しかし、フロントエンドの人がいちからJenkinsを立ち上げたりするのもさほど面倒でもないが多少の心理的障壁があるので、もっとカジュアルに利用したい。

Build・Test・Commit

Frontend/06の佐竹さんのセッションでCIを構成する要素として、Build・Test・Commitの3つがあると紹介されていた。Commitは普段Gitを使ってるから馴染み深いというかGitHub使ってるよね？みんな！！ってことで問題無いとして、Build/TestをなんとかCIサーバーでやってもらいたい。Testに関してはJavaScriptのTestなんかフロントエンドの人もやるので問題ないかと思うけど僕はそんなJavaScriptとか書かないのでよくわからないので、今回はWeb Performanceのテストをやってみるよ。

Travis・YSlow・GitHub

今回のGitHubのレポジトリ(master)にPushしたら、Travisがgh-pagesブランチに同じ内容をコミットして反映された(gh-pagesの)ページのパフォーマンスをYSlowで検証してみるという流れだ。

gh-pagesをDev環境と見立てて、Dev環境でBuildした内容がパフォーマンス的に不適切（テストが失敗）ならProduction環境にはリリースできない・させないというようなサイクルを想定している。

Travis-CI

CIサーバーはなにもJenkinsだけではない。GitHub上でレポジトリを管理しているのなら連携しているTravis-CIを使用するのが何かと都合がよい。

Travisを使うにはアカウントを連携して、自分のプロフィールから検証したいレポジトリをONにする。

Travisをどのように使用するかは.travis.ymlというファイルに記述する。Mapleでの設定は下記ファイルを見てもらえればよい。

最初の行は実行環境を指定する。node.jsを使ったテストがしたいので、node_jsを指定する。バージョンは0.8、0.10とか複数指定できる。

env:
  global:
<<<<<<< HEAD
    - GIT_AUTHOR_NAME=YOUR_ID
    - GIT_AUTHOR_EMAIL=YOUR_MAIL_ADDRESS
    - GIT_COMMITTER_NAME=YOUR_ID
    - GIT_COMMITTER_EMAIL=YOUR_MAIL_ADDRESS
=======
    - GIT_AUTHOR_NAME=your-name
    - GIT_AUTHOR_EMAIL=your-mail
    - GIT_COMMITTER_NAME=your-name
    - GIT_COMMITTER_EMAIL=your-mail
>>>>>>> bc00bb731570eceb7f151001eafb282b7ce2fe56
    - secure: "Xtk................"

TravisからGitHubにコミットするには、OAuth access tokensが必要になのでここから発行する。そんでトークンをこんなパブリックなところに公開できないので、コマンドラインのtravisで暗号化したのがsecureのところ。

$ gem install travis
$ travis encrypt -r t32k/maple "GH_TOKEN=<生成したトークン>"

こんな感じで暗号化する。詳しくは下記のサイトを参照して欲しい。

まぁ、GitHubの設定をしてるとこです。

before_script:
  - "git clone --quiet https://github.com/t32k/maple.git"
  - "git checkout -b gh-pages"
  - "git rebase master"
  - "[ \"$TRAVIS_BRANCH\" == \"master\" ] && [ $GH_TOKEN ] && git push --quiet https://$GH_TOKEN@github.com/t32k/maple.git gh-pages 2> /dev/null"

before_scriptはtestが実行する前に実行しておきたいコマンドで、ここでは、masterブランチの内容をgh-pagesにマージしてプッシュしてる。

script:
  - "npm test"

で、最後にテストコマンドを実行って流れ。

YSlow

で、次はパフォーマンスのテスト内容に関して。YSlowはFirefoxとかChromeの拡張機能でみんな使ったことあるよね？君のサイトはパフォーマンス的にAランクですよ！とか教えてくれるツール。それをPhantom.jsを使ってTravis上でも実行できるように解説してるのが以下のページ。

基本的にこの通りにやっていく。さっきの.travis.ymlで指定したnpm testってのはpackage.json の以下の部分が実行されるということ。

で、yslow.shを実行するって書いてあるから、yslow.shのファイルは以下。

  • maple/test/yslow.sh at master · t32k/maple

    ./node_modules/phantomjs/bin/phantomjs test/yslow.js --info grade --format tap --threshold '{"ycdn": 10, "yexpires": 10}' t32k.me/maple/test/fixtures/perf_test.html?${CACHE_CLEAR}

長ったらしく書いてあってややこいけど、基本的には以下のような構造になってる。

phantomjs yslow.js [オプション] <テストしたいURL>

で、重要なオプションである、しきい値の設定も忘れずに。

--threshold '{"ycdn": 10, "yexpires": 10}'

単純にテストしたいだけなので『CDN使えよ！』の項目や、gh-pagesでホストしてるのでサーバーの設定とかできないので、キャッシュの項目とか10点でもOKなように（テストが通るように）しておく（もちろん、その他の項目がダメならテストが失敗したよってメールが飛んでくる（飛んでこないようにも設定できる））。

てな感じで、これでmasterにpushするとその内容をgh-pagesにマージしてホストされたURLをパフォーマンステストするって流れが出来ました。

まぁ今回のテストページとか適当だし、そもそもgh-pagesのホストにデプロイしてる間にtestが実行されちゃって残念な状態にもなってるのであれですけど、雰囲気つかんで貰えれば幸いっす＞ｍ＜

参考リソース