Rakuten Technology Award 2012 金賞をもらいました

jenkins


昨日のRakuten Technology Conference 2012でJenkinsについて楽天テクノロジー・アワードの金賞を頂戴しました。



とても嬉しいのですが、一方でJenkinsはもはや僕個人だけのプロジェクトではないので、何だか他の人の仕事のクレジットの分も僕が頂戴しているようで恐縮です。日本（と世界）のコントリビュータの皆さん、本当にありがとうございました。


日本のJenkins communityは世界の中でも特に稀な結束を誇る素敵な仲間達の集まりです。こういうプロジェクトをやることの楽しみの一つは、みんなと一緒になにかをやる、ということです。どことなく、高校の時の文化祭のような…。なので、今後もどんどん仲間を増やして頑張りたいと思っています。賞状の文面にもありましたが、こういう賞で援護射撃してやるからもっと頑張れよ、と云うことみたいなので。


商品として金色のKoboをもらったので遊んでみます。これってjail breakできるのかな？Javaが走ればJenkins slaveにできるのですが。あとはXFDとして使うとか。



第六回Jenkins勉強会のまとめ

jenkins

Gerrit Trigger Pluginを使ってJenkinsをコードレビューシステムGerritのレビューアーにしてみよう

今や世界のどこのJenkins meet-up/user conferenceにいっても定番となったJenkins+Gerritの話です。この２つを組み合わせることで、所謂pre-tested commitという、変更を中央のリポジトリに送る前にJenkinsで検査することができます。Eclipseでデモをするというのが僕にとっては新しい部分でしたが、Change IDの自動付与がないみたいで細かいところが通常目にするデモの手順とは違っていて面白かったです。Gerritを使い始めるにはメインのGitリポジトリをGerritの中に移さないといけないので、導入する際にどういう風にチームを説得して…みたいな話を今後更に聞けたらと思いました。

おひとりさまからはじめよう、おひとりさまでもはじめよう。 〜 ある管理部門のJenkins展開への道〜


本日一番人気だったとおもわれる（参考）高野さんの発表。高野さんとは以前からあちこちでお会いしたりお話させていただいたりする機会があって、いつかは発表してください、というラブコールをしていたのがついに叶いました！高野さんが一人でJenkinsを仕事で使い始めて、それがやがて部署の中で重要なシステムになっていく…というそこはかとなく発表がドキュメンタリー風の発表でした。こういう人達のおかげで広まったのね、という印象。


Jenkins User Conference San Franciscoの活動報告・Jenkow pluginの紹介


僕の発表は、Jenkins User Conference San Franciscoでいろいろな人が披露してくれた熱いカスタマイズや独自プラグインの話と、その中から特にJenkowプラグインの紹介をしました。こういうごっついサブシステムをJenkinsに載せてくる突破力の高さというか、大変素敵な感じです。このプラグインを書いているMax Springはバグ報告でもなんでもフィードバックを送ってあげると喜ぶと思うので、よかったらお願いします。

Lightning Talks


田中さんの発表はJavaFXの話。NetBeansのプロジェクトをサーバ上でビルドするのが面倒とか、JavaFXをJenkinsが自動インストールするJDKに追加するのが面倒とか、作っている方としては具体的な改善すべき点の指摘をこういう風にしてもらうととても参考になります。



二番手の玉川さんは勉強会の中の人で、いつも裏方で活躍されてますが、今日は発表も。よく使うプラグインを10個位いれたスターターパックを作っているという話に会場の食いつきが。これはそのうち公開されるんでしょうか。ちょうどJenkins PHPをやっているSebastianも「PHPプラグイン」という名前で依存関係としてPHP関連のプラグインを集めたクラスタプラグインを作っているので、こういうのが今後はやるのかも。プラグインの集団を効率良く共有する方法などは今後改善したいと思っています。



三番手岩田さんの発表はパフォーマンステストの自動化です。LTで時間がなかったので「こういう部品を組み合わせてやっています」という概要の話だけでしたが、これはぜひfull-lengthの発表でもっと細かいところも聞きたかった感じです。ついでに、具体的なプロジェクトのひな形とかJenkinsのジョブ設定の情報があれば、それを出発点にしてパフォーマンステストを始めてみる！という人が増えてくれそうな気がします。



トリの今井さんはIntelliJの話。どこかでJenkinsの話になるのかなと思っていたら本当に直球でIntelliJの話でした。流石。僕もIntelliJのヘビーユーザーなので、今度JetBrainsからT-shirtかタダのライセンスでもせしめてIntelliJ勉強会とかやったら楽しそう、と思いました。

スタッフ


そしていつもいつも、このイベントを可能にして下さっている運営サイドの皆さん、本当に有難うございます。今回のイベントはNTTデータのJenkins本チームの皆さんとシフトの玉川さんのお陰で無事開催できました。もう佐藤さんには本当に足を向けては寝られないです。

エレベータアルゴリズムの最適化

エレベータに階数表示がないのはなぜかというブログポストを見て、この一歩上をゆく方式がニューヨークで運用されていたのを思い出したので、紹介します。


タイムズ・スクエアのマリオットだったと思いましたが、エレベータホールには、上下ボタンの代わりにテンキーで目的階を入力するキーパッドが付いています。これを押して行きたい階を選ぶと、液晶画面で何号機に乗るのか指示されます。指示されたやつの前で待っていると、やがてドアが開く、という具合です。エレベータ内には階数入力のボタンはついていないので、中に乗ってから目的階を選ぶことはできません。これだと、同じ階で降りる人を同じ箱にまとめて載せることができるので、効率は更に上がりそうですね。


ニューヨークの二箇所のホテルで見たので、結構流行っているのではないかと思われますが、一方でニューヨーク以外では見たことがありません。


追記：その後のフィードバックで、ニューヨークだけでなくサンフランシスコなどでも導入されていることがわかりました。東京でももうすぐ!?

追記：そういえば昔Towerという、ビルを建てながら住人やテナントが目指す階に効率良く着けるようにするというゲームがあってよく遊びました。エレベータとかは前に待ち行列が出来て、ストレスが溜まりすぎると怒って帰ってしまうという。これの運行アルゴリズムを俺に設計させろ！と思ったのを思い出しました。

実はもう一回日本に行きます

japan jenkins

明日から休暇で留守にするのですが、その休暇が終わると実はもう一度日本に行きます。今度の用事は以下のとおり。


まず、8/22はCEDEC 2012というちょっとawayな環境ですが、Jenkinsで学んだ開発者コミュニティの育て方について講演する予定です。まだセッション一覧には乗っていないみたいなのがちょっと心配ですが、11:20からR301会場で、とシステムには登録されているのでウェブサイトもそのうちアップデートされるはず。Jenkinsの機能とかじゃない話は久しぶりなので楽しみにしています。


次の8/23には豆蔵さんのところで、夜に「豆ナイト」というイベントをやります。JUC TokyoはJenkinsを既に使っている人向けの濃いセッションがてんこ盛りでしたが、こちらはJenkinsの初心者の人向けのイベントです。ちなみに、前回はこんな感じでした。詳細が決まり次第ここに情報がのると思うので、よろしくお願いします。


最後の8/24は、恒例のJenkinsの一日トレーニングをやります。最初のところから複数のジョブの連携みたいな応用の話まで、一日にしては結構濃い内容になっていると思います。僕が講師をやるので、どんな質問でも答えられるので、ぜひ参加してください。

ikikkoさん有り難うございます

jenkins ikikko

Jenkinsでは世界中で色々な人にお世話になってきた。今日はその中の一人、日本のJenkinsコミュニティの大黒柱ikikkoさんの話をしよう。ikikkoさんの事ばかり書くとJenkinsコミュニティの他の人の貢献を過小評価されそうな気もするが、それは別な機会に譲る事にして、今日はikikkoさんの話をしよう。


日本のJenkinsコミュニティは世界でもずば抜けて組織化されている。これが今日あるのはikikkoさんの力によるところが大きい。日本のJenkinsコミュニティを一身に体現する男、それが「リアルJenkinsさん」という愛称の本当の意味だと思っている。決してJenkinsおじさんのようにこき使われているという意味ではありませんよ！


オープンソースプロジェクトというとプログラムを書く人が重視されがちである。でも、実は色々な人が必要なのだ。ikikkoさんが果たしているのはミートアップや勉強会を組織するという活動である。


人間の活動なら何でもそうだと思うが、「これこれこういうソフトウェアを書く」みたいなドライな目標だけよりも、そこに一緒に参加する人達との良い人間関係があると、同じ作業もずっと楽しくなる。オープンソースも全く同じだ。これをコミュニティという。上手く回っているプロジェクトにはコミュニティが必ずある。


Jenkinsではプラグインやアップデートセンターといったようなソフトウェア上の仕組みで開発者のコミュニティを作りやすくして、これが大いに寄与した。勉強会の組織とはユーザーのコミュニティを作るという事で、これに連なるとても大事な仕事だ。


オープンソースのコミュニティ作りで難しいのは、多くの人がボランティアで参加しているという点だ。明確な上下関係もなければ、ゴールさえ一致していない場合も多々ある。それでいて、コミュニティのメンバーの同意をある程度取り付けないといけない。ソフトパワーを駆使して人に働いてもらわなくてはいけないし、何処かで遅滞が生じたらいつでも自分が入って行って解決出来なくてはいけない。このような人間関係は一朝一夕には作れない。だからJenkinsユーザカンファレンスみたいな大きなイベントの開催は、今までの積み重ねの上に成り立っている。今まで5回開催された勉強会があって、その中で得た仲間があって、スポンサーをしてくれる会社があって、その上で初めて可能になったことなのだ。


今回のJenkinsユーザ・カンファレンスには、通常の勉強会の手間に比べて、ずっと手間が掛かっている。部屋ごとに担当者を割り当てたり生放送の手配をしたり、スタッフの食べ物を用意したり、100名規模の懇親会を申し込んだり、スポンサーにお願いをしたり、配布物の管理をしたり、Ｔシャツやステッカーを作ったり。通常の勉強会では、ikikkoさん自身がこういうタスクを実行するのだが、今回は個々のタスクはスタッフが担当して、ikikkoさんはそれを統括するという管理的な役割をしてくれた。この両方ができちゃうというは素晴らしいことで、ここにikikkoさんの成長を感じた。こういう人を身近に見られるのは大変嬉しい事だ。


ikikkoさんがその手腕を存分に発揮しがいのあるJenkinsという大きな器を作る作業に、僕自身も携わっている事を誇りに思う。やはり職人の道を選んだからにはこうやって尊敬できる人と一緒に仕事がしたい。


ikikkoさんの匠の凄さは外からは分かりにくい。なので、常々この人の素晴らしさを人に伝えなくてはと思っていた。


今日はJenkinsユーザカンファレンスにかこつけて、ようやっとこれを書く事ができた。ikikkoさん本当に有難う。

日本へ行くぞ！

japan jenkins

来週から久しぶりの日本行きです。今回はいまだかつてなくイベントがてんこ盛りです。一般向けのイベントは以下の通り。

これ以外にもお世話になる皆様、宜しくおねがいします。ちょっと無茶しすぎなような気もしなくもないのですが、これが終われば夏休みだし、場所は日本だし、きっと大丈夫でしょう。

BuildHiveに直接プッシュできるようになりました

jenkins cloudbees buildhive


BuildHiveではリリース当初からプルリクエストを自動ビルドする機能がついていますが、今日、これに加えて開発者がBuildHiveに直接変更をgit pushする仕組みを追加しました。この仕組みは「検証済みマージ」といいます。



プルリクエストは主に外部の開発者が変更を提案したり、コミッタが他のコミッタに対してコードレビューを依頼する時などに使われる仕組みです。なので、通常、開発者は自分の変更をわざわざプルリクエストにせず、直接リポジトリへプッシュしているのではないかと思います。ただし、それだと問題のあるコミットがリポジトリに混入してビルドが壊れる、ということが起こりえます。検証済みマージをすることで、これを防ぐことができます。この機能は次のように動作します。



まず、GitHub上でbuildhiveユーザーをリポジトリのコラボレータとして追加してください。これによって、BuildHiveがリポジトリに変更をプッシュできるようになります。BuildHiveがこれを自動でやるのはまずいかと思ったので、現時点ではこれは手動でおこなってもらう必要があります。



次に、BuildHiveにログインして、ジョブのページを表示してください（例）。画面左から「Git Repository for Validated Merge」を選びます。コピーボタンを押して、「git remote add」コマンドをクリップボードへコピーし、このコマンドをワークスペースで実行してください。これでBuildHiveがリモートリポジトリとして追加されます。




準備はこれで出来上がりなので、いつもやっているようにコードを編集し、コミットを作ってください。プッシュする用意が整ったら、いつものように「origin」にプッシュするのではなく、「jenkins」にプッシュしましょう。下の例ではmasterブランチをプッシュしていますが、他のブランチで作業していたらその名前に置き換えてください。


$ git push jenkins master



BuildHiveは変更を受け取ると、GitHub上での現在のそのブランチの先端とマージした上で、ビルドとテストを行います。もしマージの結果がテストに合格した場合は、そのマージの結果がGitHubへプッシュされます。






もし運悪く、変更に不備があれば、テスト失敗が通知されます。その時点でやりかけだった仕事を一度中断して、不備のあった変更を最修正しましょう。どの変更をBuildHiveにプッシュしたか覚えておくのは面倒なので、BuildHiveは不備のあった変更をチェックアウトしやすいようにタグを公開してくれます。コマンドをコピペしてタグを取得しましょう。







$ git stash

$ git fetch -n ssh://anonymous@buildhive.cloudbees.com/kohsuke2/sandbox-ant tag changes/45

$ git checkout changes/45

$ … make edits ...



不備のあった変更に新たなコミットを追加して問題を修正してもいいですし、rebaseやcommit --amendなどを使って破壊的な変更をおこなっても構いません。不備を修正したら、それを改めてBuildHiveに送ってテストしましょう。BuildHiveに修正を送ったら、前に行なっていた作業に戻りましょう。




$ git push jenkins HEAD:master

$ git checkout master

$ git stash pop

… resume the work you were doing ...



もし変更の不備が発見された時にあなたが既に帰宅していたら、他の同僚がかわってこの作業を行うこともできます。



開発者の時間は貴重です。開発マシンがテストの実行を終えるのを待つのではなく、さっさと変更をBuildHiveに送ってしまって、次の作業にとりかかりましょう！この機能を利用すれば、開発者はテストの実行をローカルで行う必要はなくなります。編集→コミット→プッシュだけを繰り返せばいいのです。



なお、この機能はJenkins Enterprise by CloudBeesについている機能をBuildHive上に展開したものです。Jenkins Enterprise by CloudBeesを使えばこのような作業フローを任意のGitリポジトリに対して利用できます。