継続的インテグレーションについて、Ruby勉強会@札幌-18 で発表しました

先日行われたRuby勉強会@札幌-18で、Ruby勉強会にもかかわらず空気を読まず、継続的インテグレーションについて発表しました。

継続的インテグレーション - Ruby勉強会@札幌-18
View more presentations from hotchpotch

継続的インテグレーションは複数人開発ではやるべき価値がある手法だと思ってますが、実際に実践してみないと価値をなかなか体験できない物だと思っています。

継続的インテグレーションについて語る際に、言葉で伝えにくい部分がある。それは、継続的インテグレーションは開発全体に関わる「パターン」への移行をもたらすものだということであり、こればかりは、実地で体験してみないと理解しがたいのだ。

継続的インテグレーションの恩恵

スライドの中では、実際にクックパッドで継続的インテグレーションを行っていて感じた価値、その結果変わった開発サイクル・プロセスについて書いてますので、良かったらご一読下さい。

Ruby札幌について

Ruby勉強会自体ももちろん楽しかったんですが、感動したのがRuby札幌コミニュティの暖かさでした。参加のやりとりのメールでも非常に丁寧にしていただいたのはもちろん、札幌に来るにあたって美味しいお店をまとめていただいたり、懇親会の後Ruby札幌のメンバーの方々にわざわざホテルまで見送りに来ていただいたり、観光プランを一緒に考えてくれたり、観光で小樽に行くと決まったら小樽で美味しいお店をまとめてくださったり、ほんと楽しくて暖かい方ばかりで、すごい良いコミュニティだなぁと感じました。まだ是非北海道行ってみたい、と感じさせられました :D

rubygems-test で rubygems インストール時にテストを行う

Ruby のパッケージングマネージャの rubygems と Perl の CPAN と比較して、rubygems の残念なところの一つに『インストール時にテストを行わない』ことが挙げられます。rubygems は gem install package で一発で入れられる事は便利なんですが、インストール時にテストが行われないため、実際にその環境で正しい挙動をするとは限りません。また、rubygems で入れたパッケージのテスト方法もコマンド一発で簡単にできるわけではないのでめんどくさかったりします。なにより問題なのが、インストール時にテストが行われないため『開発者がテストをさぼりがち』になってしまいます*1。
最近 rubygems でも CPAN と同じように、インストール時にテスト可能なパッケージはテストを行い、失敗したら基本的にインストールできない(設定で変えられます)仕組みを持ったライブラリ、rubygems-test が登場しました。

インストールは簡単で

gem install rubygems-test

して、~/.gemrc の設定に以下の感じで設定を追加します。(詳しくは https://github.com/rubygems/rubygems-test とか読んでください)

test_options:
  auto_test_on_install: true # package のインストール時に自動でテストを行うか
  test_on_install: true # package のインストール時にテストを行うか(Y/n)で尋ねられる
  install_development_dependencies: true # add_development_dependency なパッケージもインストールするか
  test_development_dependencies: false # add_development_dependency なパッケージもテストするか(たぶん)
  upload_results: false # テスト結果を test.rubygems.org にアップロードするか
  force_install: false # テストに失敗しても強制的にインストールするか
  force_uninstall_on_failure: false #  テストに失敗したらアンインストールするか(たぶん)

これで"テストの設定が適切にされている"ライブラリの場合、自動でテストが実行されます。"テストの設定が適切にされている"ライブラリというのは以下の条件を満たしてるライブラリです。

  • パッケージに .gemtest が含まれている
  • rake の test タスクがある

Jeweler などでパッケージのひな形を作ってる場合、Gemfile から勝手に依存ライブラリ周りの設定は生成されるので、.gemtest を作って git add して、rake spec なタスクしかなかったら、rake test なタスクで spec が実行される(ちょっと微妙ですが…)タスクを用意すればそれだけで終わりで簡単ですので、gem ライブラリの作者は用意すると良いと思います！
また、rubygems-test を入れると gem test package 名でテストを実行でき、結果のレポートを test.rubygems.org にアップロードすることもできます。

というわけで、最近は rubygems も徐々に CPAN に近づいてきた感があります。まだ rubygems-test プロジェクトは始まって4ヶ月ぐらいしかたっておらず、rubygems によりテスト文化を根付かせるためにも、是非みなさん使ってみましょう。特に gem の作者は是非 .gemtest を設置して、インストール時にテスト可能なパッケージを作っていきましょう :D

*1:CPAN ならテストが無かったりテストが適当なパッケージはクオリティが低いライブラリと認定しますよね

大江戸Ruby会議01 高速なテストサイクルを回すには

本日大江戸*1で行われた大江戸Ruby会議01で、高速なテストサイクルを回すにはという内容で発表してきました。

大江戸Ruby会議01 高速なテストサイクルを回すには
View more presentations from hotchpotch

テストを速くするには二パターンあり、一つは単体実行時の速度・フィードバックの高速化、もう一つはすべてのテスト実行時の高速化があると思っていて、それらについての話です。ぎゅっとまとめると、前半の単体実行時の速度・フィードバック高速化には spork / prefetch-rspec / autotest / watchr を使おうという話と、後半は REE / parallel_tests による高速化・並列実行、remote spec によるリモートマシンでの分散テストについての話です。
特にオレオレプロジェクトの prefetch-rspec と会社で運用してる remote spec の話*2が受けが良かったのが嬉しかったです。prefetch-rspec は是非使って叩いてパッチなりコントリビュート(もしくはgithub.com/asakusarb プロジェクトとしてリリース)してもらえたりするととても嬉しいですね :D

また、大江戸Ruby会議01 自体も面白くて刺激的だったので、スタッフの方々、スピーカの方々、参加者の方々、どうもありがとうございました！

*1:清澄白河

*2:ちなみに偉そうに話してましたが remote spec は僕が作ったんじゃなくて、同じ開発基盤チームの同僚のアイディアと実装です。すごく改善されて同僚に超感謝