Archive for 2012年7月

Jenkinsのコミュニティってすごいなぁと思った@Jenkinsユーザーカンファレンス

7月 30, 2012

2012/07/29に行われたJenkinsユーザーカンファレンスに参加してきた。
1000人以上の参加登録が行われ、国内で行われるIT系のカンファレンスとしては有数な大きな規模で盛り上がったようだ。
大きなカンファレンスが有志で行われることは、Jenkinsが多くのエンジニアにとって有用なツールであり、また、多くのエンジニアに愛されていることの証拠だろう。

◯優れたツールをつくるコミュニティには貢献の意識が中心にある
川口さんの基調講演ではJenkinsの現状やこれからの取り組みについて聴いた。
話を聞いて考えたのは、
なぜJenkinsが多くのエンジニアに愛されているか
なぜJenkisnのコミュニティは活性化しているのか
ということだ。

この答えは非常に単純で、
エンジニアたちへの貢献を一番に考えた取り組みがなされているから
だろう。
Jenkinsの取り組みとして
– よくある作業をやりやすくするためのUIの見直し
– pluginによりユーザーが好みの機能を拡張しやすくすること
– 頻繁にアップデートができないエンタープライズでの利用者に向けてLTSの用意
など利用者がどこで困るのか、どんな対応をしたらうれしいのか、という点をよくみて対応が進んでいるように感じた。

またJenkinsのおすすめpluginを集めたおすすめpluginパックのようなものを作る予定があるらしい。
Jenkinsはpluginが豊富にある一方で、個人的にはどんな便利なpluginがあるかほとんど把握できていないので、この取り組みは非常に良いなと思った。

1000人も集まるカンファレンスを有志で開催できてしまうほどパワーのあるコミュニティは、Jenkinsという優れたツールに引き寄せられた人たちによって成り立っている。
Jenkinsに引き寄せられるのは、Jenkinsがエンジニアたちに貢献をしているからだ。
そして、Jenkinsが優れたツールであるのは、素晴らしいコミュニティとそこに集まる人たちの貢献があるからだ。

川口さんのお話を聴いていて、Jenkinsというツールとそのコミュニティは、エンジニアたちと良い循環をもった関係を築いており、エンジニアとコミュニティが相互に貢献の意識を持っているからなんだと感じた。

◯buildhiveが素敵
これも川口さんお話で出てきたのでけど、buildhiveというツールが非常に良い。
というかものすごく期待できる。使いたい。
現在、gerritを開発で使っているのだけど、その理由は1つ。
中央のリポジトリにバグを含むコードが入る確率を低くしてくれるからだ。

今回のカンファレンスでもgerritとjenkinsの組み合わせを利用した事例を発表していた方がいた。
その方も話していたけど、gerritを利用すると
– gerritにpush
– Jenkinsによるビルドとテストの実行
– test実行後に人間によるcodereview
– ビルドとテスト、コードレビューをすべてにクリアしたら中央リポジトリにマージ
というフローで開発ができる。
エンジニアたちがpullをするリポジトリには、ビルドとテスト、レビュー済みのコードが入ってることになる。

buildhiveというツールは、githubのpullrequestを利用してこれとほぼ同じことが出来る。
つまり、pullrequestを行ったプログラムにたいしてJenkinsでビルドとテストが実行できる。
そして、ビルドとテストを通過したものをコードレビューをした後に、受け入れるかどうかの判断ができる。

gerritは魅力的な一方で、管理や利用の面で覚えることが多い。
一方で、githubは個人で利用している人も多い人気ツールだ。
おなじことができるなら、githubとbuildhiveのほうが導入が早いかもしれない。
buildhiveがあるならgerrit入らないくなってしまうかも。

余談だけど、設定周りの管理はpuppetを利用している事例をよく聴いた。
名前は知っているけど何ができるかよくわかっていないので、ちょっと勉強してみたい。

◯自働化のキモは適切なジョブの分割
自働化で意識しておきたいこと下記の3つかな、と感じた。
– どこで、何が原因で処理が失敗したか検知しやすくする
– 時間のかかる処理を並列で行えるにする
– 失敗したジョブの再実行しやすくする

これらを達成するコツが適切な単位でのジョブの分割だろう。
というか、上記の3つがジョブを分割する際の指針になるような気がする。

◯Jenkinsを中心にすえて開発からデリバリーまでのプロセスを見直したい
サービスの開発から運用までをやっていると課題になるのは品質だ。
サービスの品質を維持するためには、プログラムのバグを出さないという基本からユーザーや開発に必要なドキュメントの整備まで、ひとつの機能を作ったり改善したりする際に行うべきことは多い。
現状、いわゆる「どのような状態をサービスの出荷条件とするか」というDone定義がチームでまとまりきらず、それによる作業の抜けが起きることがある。
また、やらなきゃいけないとわかっていても何かと言い訳してやらないこともある。

Doneを定義し実行する、という点においては、受け入れテストのレベルで自働化の必要性を感じた。
プログラムがどう動くかだけでなく、どのような目的を達成するか、という観点からテストが書かれて自働化することに加えて、コードのメトリクスをとり、テストの網羅率などをテストの成否の基準に加えたり(たしかCoberturaを利用していた)
単にバグないだけでなく、コードの品質も自働化により担保するなどの取り組みをおこなう。
また、Javaを使っているならJavadocをもとにドキュメントを生成する仕組みもある。

どのような品質のコードで、何が達成され、ドキュメントなどのどのような成果物が必要か、という観点から出荷すべて成果物を定義するきっかけとなるのが受け入れテストなのだ。
そして、Jenkinsにはそれを助けてくれる仕組みが用意されている。
Done定義そのものはチームが考えて決めてゆくものだけれども、Jenkinsを利用して自働化できることに注目することでDoneの定義に含めやすくなる成果物も増えるだろう。

gerritとJenkinsを利用したプロセスの話だと、開発のプロセスが固まるまでは半年ぐらいはかかったということだった。
はじめからモノゴトはうまくいかないし、問題意識があるからてすぐに改善できるわけでもない。
時間を捻出して少しずつ進めて行きたい。

で、そのための手段としてやはりベロシティやバグの発生件数、コードのテストの網羅率など利用価値の高い数値を簡単に取る仕組みを導入したいと考えている。
やはり現状がどうなっているのか、感覚値じゃなくて実測値から判断したい。
そろそろ取り組む余裕がでてくるはずだ。

◯最後に
今回のカンファレンスに参加して、Jenkinsは単にbuildとtestを自働化するツールという印象ではなくなった。
deployなどを含めて、開発から運用というプロセスにおいてあらゆる箇所の自働化の中心的なツールになってゆくことが期待されるツールなのだと感じた。

運営に携わった方々には、大変お世話になりました。
皆様、どうもありがとうございました。

チャラン・ポ・ランタンのライブがおもしろかったのでひさびさにブログを更新してみる

7月 22, 2012

JAZZ ART せんがわ2012というイベントで非常に面白いライブを見てきた。
http://www.sengawa-gekijo.jp/kouen/07423.html

アーティストの名前は、チャラン・ポ・ランタン。

jazzを聴けると思っていたんだけど、どう考えてもジャズじゃない。
あまり音楽を聞かない僕の知識を総動員して考えると、あれは昭和歌謡だった。
普段ほとんど音楽を聞かない僕でも、どこかで聴いたことのあるような懐かしさを感じる音楽と、人間が表には出したがらない自分の心のうちを描いたような詩が印象的だった。

ライブを聞いていると、人間の表に出しづらい心の奥底にある感情をテーマに書かれた連作短編の小説を読んでいる気分にさせられる。

1つ1つの曲に物語があり、1つの曲ごとに完結している。
そんな1つ1つの曲がつながって、ライブが1つの作品になっているという印象だった。

下記に彼女たちのHPのURLを貼っておいたので確認してほしいのだけど、可愛らしい彼女たちの風貌からは想像できない詩の内容、そして、迫力のある歌声に圧倒されてしまった。

もう一つ、びっくりしたのはアコーディオンの音色。
テレビでしか聴いたことがなかったので、うまい人が弾くアコーディオンを生で聴くととすごく綺麗な音がするんだな、と感心してしまった。

お店にお酒がなかったので、はじめてライブをシラフで聞いたけれど、とても楽しめた。音楽素人の僕が久々に皆に教えて回りたいな、と思ったアーティストに出会ったライブだった。

チャラン・ポ・ランタンが気になる方は下記のHPで情報チェックしてほしい。(というか、たぶん結構有名なんだろう)
今度、フジロックにも参加予定らしい。
http://charan-po-rantan.o0o0.jp/