DevLOVE-CI「たとえ世界が終ろうとも、僕はビルドをケイゾクする。」へ行ってきた

Event

水曜の夜、DevLOVEの勉強会「たとえ世界が終ろうとも、僕はビルドをケイゾクする。」へ行ってきました。今回は、継続的インテグレーションがテーマです。

参加した目的は、既存プロジェクトに継続的インテグレーションを導入することは、意味があるか、現実的に可能か、やろうとすればどれくらい大変かについて、考えるためでした。

CIについて、自分は知識がありません。2008年秋のJJUGクロスコミュニティカンファレンスで、川口さんの講演を聞いた程度です。

# 余談ですが、この講演はとても面白かったです。上のリンク先の発表資料をブラウザから開こうとしたら、ファイルが壊れているといわれて開けませんでしたが、ダウンロードすれば見ることができました。未見の方は、ぜひ。

その後、身近でHudsonを使っているJavaプロジェクトがあることを知って、さらに興味をもちました。ただ、自分自身は、.NETのプロジェクトにいるためもあり、まだ使う機会がないままです。しかし、最近、プロジェクトの今後について考える機会があり、今のうちにビルド環境を整えられないかな、と考えるようになりました。

Hudson非（未）ユーザなのに参加させていただき、ありがとうございました。以下、印象に残った話や所感をメモしておきます。

CI、Hudsonについて：cactusmanさん

CIとは

CIは新しい概念ではない。2000年にファウラーさんが出した概念で、2006年にはJava Worldで角谷さんが話をされている。

CIのメリットは、関心事を分離できること。ビルドを機械に任せることによって、人間はテストについて考えることができるようになる。（このあたりは、ご本人のブログに分かりやすい解説があります：「継続的インテグレーション」について - cactusman日誌）

では、なぜ流行しないのか。それは一言でいうと、大変だから。テストを書くのも大変だし、エラーに対処し続けるのも大変…。CIは、多人数・分散開発に向いている。

しかし、プロジェクトの規模にかかわらず、「関心事の分離」の恩恵は受けられる。小さいプロジェクトだからCIをする意味がないわけではない。

CIをはじめるために必要なもの
  • あった方がよいもの
    • バグトラッキングシステム
    • インスペクション
      • 静的なコードチェックツールのこと
    • XFD
      • 結果が得られる感触がよい
      • 危機感を持てる
導入と運用について
  • CIツールは、プロジェクトの最初から導入すると、労力が少なくて済むので理想。
  • エラーを出した犯人探しをしてはいけない。
  • 導入しただけで万z区しない。エラーが出たら放置しない。
スローテスト問題について

システムが大きくなり、テストが多くなると、ビルドに時間がかかる。時間がかかると、モチベーションが下がる。

スローテスト問題の改善策は、次のようにいろいろ考えられる。

  • CIサーバをクラスタ化する
  • ビルドする範囲をローカルとサーバで分ける
    • ローカル：修正モジュールのみ
    • サーバ：すべて
  • テストをマルチスレッド実行する
  • モックを利用する
  • 実行順序を変えて、時間のかかる部分を後に回す
  • マシンのスペックを上げる

「なにより大事なのは、改善のための工夫をすること」とのことでした。

Hudsonの現場での活用：川島さん

100人以上の現場でHudsonを運用するコツや、楽しくするための工夫のお話。

  • エラーを出した人はあえて特定。アスキーアートでソフトに伝達
  • エラーだったテストを通るようにした人を祭り上げる。楽しさを演出
  • エラーが出たら光で通知。警子ちゃん。16万円
  • エラーが出たら音で通知。萌えボイス。1時間（合成）
  • 新しくプロジェクトに入る人のために、約5日間の立ち上げコースを用意

実際にいくつか見せていただいて、次から次へと出てくる工夫の数々に圧倒されました。

ワールド・継続的・カフェ

自分がいたテーブルのテーマは、「ツール」あたり。

同じテーブルに、新人の方がいらっしゃいました。その方いわく、「開発現場にあるツールのそれぞれが、何ができるのかと、どんな出力をするのかを、どこかに書いておいて欲しい」

たしかに、使ったことのないツールを押しつけられて、いきなり開発するのはむずかしいですよね。ツールの導入にはトレーニングが必要です。それには時間的なコストはかかりますが、必須だと思います。それを思い出させてもらいました。ありがとうございます。:-)

所感

cactusmanさんが、「CIサーバは物理マシンである必要はなく、むしろ仮想マシンの方がよいと思う」とおっしゃっていました。クラウドを利用するのでなくても、仮想マシンの方がいいんでしょうか。このあたり、懇親会でもうちょっと聞いてみたいと思っていたのに、ウッカリ忘れてました。うちのプロジェクトは、開発もテストも本番も仮想マシンなので、どのへんにメリットがあるのか気になります。

さて、私事ですが、参加目的に立ち返ります。「既存プロジェクトに継続的インテグレーションを導入することは、意味があるか、現実的に可能か、やろうとすればどれくらい大変か」？

意味があるか

意味があると思いました。やりたいことに集中するために、自動化の元がとれる部分はできるだけ自動化したいです。

現実的に可能か

技術的には可能だとわかりました。.NETのシステムにHudsonは使えないと思い込んでいましたが、懇親会で伺った話によると、がんばればできるとのことなので（NAntを使うのかな？）。ただ、いまのプロジェクトで導入するには、検証にかなりの工数がかかるとも思いました。

たとえダメでも、次のプロジェクトや、その次のプロジェクトでは使えるかもしれません。だから、それまで「CIを導入するなら開発の初期がベスト」という話を覚えておきます。

やろうとすればどれくらい大変か

とにかく、自動実行できるテストを整えるのが大変そう。

いまのプロジェクトではWebアプリケーションを作っています。テストは画面を操作して実行。だからもちろん、テストケースやテストデータはあるのですが、機械で自動実行できるテスト群はありません（一時期、キャプチャアンドリプレイツールの導入を検討したけど、スクリプトのメンテナンスに手間がかかりすぎるのでボツにした）

とはいえ、自分にできること、自分がやりたいことは、CIの導入を目的化することではありません。引き継いでくれる人が開発しやすい親切な環境を整えることです。だから、次の順番で、できるところまでを地道にやることになりそうです。

  • 自動化できるところだけでもテストを書く
  • 上に対するテストの自動実行環境を作る
  • 自動ビルド環境を作る
  • 新しくプロジェクトに入る人のための立ち上げコースを作る
    • システムやプロセスの説明に加えて、各開発ツールの利用方法を説明する

こんなところかな。

お礼

とても面白かったです。上のように悩んでましたが、頭をちょっと整理できたし、なにより勉強になりました。papandaさん、発表してくださったお二方、ワールドカフェや懇親会でお話ししてくださった方、ありがとうございました。