Jenkins ユーザ・カンファレンス 2012 東京で話を聞いてきました

Jenkins ユーザ・カンファレンス 2012 東京で話を聞いてきました。

John Smart「Jenkins によるよる自動受け入れテストから継続的デリバリーまで」

ビジネスゴールに貢献する価値に集中する。ビジネスに貢献しないことは、すべて無駄だ。
Business Goal -> Features -> Stories -> examples へブレイクダウンしていく。

これはリーンスタートアップや、アジャイル開発なんかの考え方に近いと思います。

受け入れテストの自動化が、リリースサイクルを速くする。
メトリクスがしきい値を下回ったら、ビルド失敗にする。たとえば、コードカバレッジなど。

テストを自動化する時間 < 手動でテストをする時間、が成立するというのが条件だと思います。でないと、抵抗にあうんじゃないでしょうか。その見極めが重要だと考えています。

もうひとつ気にしているのは、そういう受け入れテストをしやすい設計にする、という仮説です。作りやすさではなくて、テストのしやすさ、すなわち、価値の測りやすさを、設計の方針に組み込むのがいい、という仮説を持っています。

出荷可能であるために、品質が高いこと、そして、品質が高いことを確信しているとことが大事。

どのくらいの品質なのかを知っている、という状態にしたいのです。バグがあるのが分かっていて、それがどの程度プロダクトに影響があるのか、そして、ビジネス価値に、どの程度影響するのか、が前もって分かっていて、受け入れ可能であれば、リリースできると思っています。ので、こういう考え方には、勇気づけられました。

R. Tyler Croy 「飛行機を飛ばしながら直す方法教えます：JenkinsとGerritによる継続的デプロイメントの実践」

反復的に構築していくプロセスなのである。

手動でデプロイしている会社に入って、開発を続けながら、継続的デプロイメントを浸透させていった過程の話でした。これを一番聞きたいのです。

リリースの何%が失敗して、リリースあたりどのくらいコミットがあって、とかを最初に測定しているのがすごいですね。でないと、効果が分からりませんからね。

7台並列でやって、テストが終わるまで15分かかる。これは、本番サーバに問題があってたときに、修正するまで最大で15分かかるってことだ。

なるほどなぁ。テストに時間がかかるということは、ビジネス価値の提供が遅れるということでしょう。ビジネス価値につなげる考え方を意識せねばなぁと思います。

データマイグレーションが難しかった。データマイグレーションが許される期間があって、その期間以外はマイグレーションがあったら fail させる。マイグレーションが発生したときには、人間がレビューするようにしている。100% 自動化するのは、テストやステージング環境のデータは、本番と違うので、無理だろう。なので人間の目が必要。

ここはやっぱり難しいですよね。KVS の場合はスキーマによる制約がないので、以前書いたエントリのような、アプリケーションでのアプローチが使えますが、RDB だと難しいですね。

まとめ

絶対完璧なプロセスをいきなり導入しようとするのではなく、反復的にだんだん作っていくこと、ビジネス価値に集中すること、がふたりの共通点だったと（勝手に）思いました。というわけで、私も徐々にやっていきます。まとまったら、どこかで発表したい。

（追記）
そうそう。むやみにプラグインを使うのではなく、Makefile で動くようにしておいて、Jenkins はトリがで make して通知するようにしておくといい、というアドバイスというか実践をしている、という話を聞きました。Jenkins の設定がいっぱいあると大変そうなので、Makefile で解決するのはいいなぁと思いました。通知に何を使うかを聞いたら、XMPP だそうで。にゃるほど。