mixi engineer blog

*** 引っ越しました。最新の情報はこちら → https://medium.com/mixi-developers *** ミクシィ・グループで、実際に開発に携わっているエンジニア達が執筆している公式ブログです。様々なサービスの開発や運用を行っていく際に得た技術情報から採用情報まで、有益な情報を幅広く取り扱っています。

Jenkins 勉強会で発表しました

システム本部技術部たんぽぽグループの加藤和良です。すこし前の話になりますが Software Design 2012年2月号 にテストのはなしを書きました。gihyo.jp から全文が読めますので、ぜひご覧いただければと思います。なお、現在発売中の2012年3月号にも弊社の佐藤が寄稿しています。

この記事がきっかけになり、先日おこなわれた 第五回 Jenkins 勉強会 でも発表の機会をいただきましたので、その スライド を公開します。

会場の識字率の高さを考慮し (話すことを一字一句書くと先に読まれてしまうので) スライドは文字少なめで作りました。これだけ見ても何を話したかよくわからないと思うので、いくつか補足します。

Jenkins で Perl のプロジェクトを管理する

はじめに、Jenkins で Perl のプロジェクトを管理するための、一般・基本的な部分について説明しました。Jenkins はシェルスクリプトの実行機能があり、プロセスの終了ステータスも適切にとりあつかってくれるため、コミットごとにテストを実行する、みたいなことは非常に簡単です。 しかし、どのテストが失敗したか、長すぎる・複雑すぎるメソッドはないか、テストのカバレッジはどのくらいか、といったことを調べるには、いくつか追加のソフトウェアが必要です。 これらはそれぞれ、Jenkins やそのプラグインが期待するフォーマットの XML ファイルを、Perl のテストや、ソースコードから生成してくれます。
XML is like violence -- if it doesn't solve your problems, you are not using enough of it
XML を使いこなしましょう。

mixi における Jenkins と、そのちょっと変わった使い方

次に mixi における Jenkins の構成を説明しました。ちょっと変わっているのが HTTP2IRC ゲートウェイの Ikachan の存在だと思います。mixi では Jenkins の IRC プラグインを使わず (つい最近までは使っていました)、ビルドスクリプトの中から Ikachan に HTTP リクエストを送ることで、結果の通知をしています。

ミクシィ社内では IRC をよく使っているため、通知にも注文が多いです。これらの要望は Jenkins の IRC プラグインだけでカバーしきれませんし、この部分に限れば再実装 + メンテナンス + 社内の開発者が社内でしか通じない知識を学ぶことのコスト、もそれほど高くありません。また IRC 通知のメッセージはこのほうがもっと見やすいと思う、みたいな話もソースコードをまじえて議論するべきだと思います。

さらに、mixi のテストが遅いという問題を紹介し、それに対する対抗策として、最近変更されたファイルに対応するテストを実行する "recent" job と、任意のブランチに対するテストを、Jenkins の Web インターフェースやスレーブ管理にのっかった形でリモートで実行する "try" job について、その実現方法を紹介しました。スライド中の表は Google Testing Blog の Test Sizes からの引用です。

Jenkins 自身にふみこもうとすると Java や Groovy, JRuby などの言語がよく出てきますが、実は Jenkins は HTTP 経由でアクセスできるたくさんのインターフェースを持っています。これらを使えば、Perl でも Erlang でも、Jenkins からいろいろな情報を引き出したり、命令を下したりといったことができるようになります。

機能トグルと New Testamentality

最後に、ビアバッシュもあるということなので、自分の中でもまとめられていない、いくつかの関係ありそうな話題を紹介しました。 2009年、Flickr のブログに不思議な記事が公開されます。Flipping Out いわく、Flickr にはブランチがないらしいのです。
Flickr is somewhat unique in that it uses a code repository with no branches; everything is checked into head, and head is pushed to production several times a day.
はじめて読んだときはその意味があまり理解できなかったのですが、2010年になると、かの Martin Fowler 氏まで Feature Toggle と言い出します。
One of the most common arguments in favor of FeatureBranch is that it provides a mechanism for pending features that take longer than a single release cycle. Imagine you are releasing into production every two weeks, but need to build a feature that's going to take three months to complete. How do you use Continuous Integration to keep everyone working on the mainline without revealing a half-implemented feature on your releases? We run into this issue quite a lot and feature toggles are a handy tool to deal with it.
氏はトグルのうち実行時に設定されるものについて、こうも説明します。
Run-time toggles make it easier to set up your build pipelines and to run tests with various configurations of features. It also facilitates canary releasing, A/B testing, and makes it easier to roll-back should a new feature misbehave in production.
そして、2011年の Google Testing Automation Conference の Opening Keynote を飾った Alberto Savoia Da G. R. の、その名も Test is Dead です。講演で氏は Old Testamentality は "Focus on building it right" だが New Testamentality は "Focus on the right it" なのだと主張していました。

ビアバッシュの最中にも「継続的インテグレーションってあいまいな言葉で、ビルドしてるひとも、テストしてるひとも、デプロイまでしているひともいるよね」というはなしがありました。

継続的に trunk に機能を統合していくのは「継続的インテグレーション」の一種と言えるのではないでしょうか? あるいは、ブランチを持たないことで (もうちょっと平和な方法もあるとは思いますが...) すべての新機能が即座にリリースできるなら、それを顧客の一部にとどけて A/B テストするようなことが New Testamentality なのではないでしょうか?

だんだん空気が薄くなってきたので、今日はここらへんで終わりにしておきます。それではまた。