日本Jenkinsユーザカンファレンス2012東京に行ってきた

f:id:saisa6153:20120729195431j:plain

開催前々日になって存在を知った日本Jenkinsユーザーカンファレンス。飛び込みで参加した。

今まで参加した勉強会の規模とは比較にならない1000人のエントリーにびびった。

何よりJenkinsの存在を二週間くらい前に知ったばかりの僕がいけるのかよっていう不安。

 

まず人生初めての法政大学。立派すぎて大学ってかもはや企業的な何かだろこのビル。

老朽化が激しく地震が起きたら外付け非常階段が落ちると噂され構造上はしご車が入って来られないため救助も消火も期待できない、大量の有機溶媒をはじめとする化学物質を満載している工学部棟を有するウチとは大違いですね。

講堂も立派。

f:id:saisa6153:20120729105917j:plain

この「さったホール」がメインの会場らしい。

 

タイムテーブルを見て、Jenkinsの運用に関するようなテーマを聴講した。

 

あと長文でグダったエントリになっているので初めに僕向けのまとめを書く。

satta-2:継続的デリバリとsatta-3:継続的デプロイメントを組みわせて環境を構築してみたい

 

①satta-1 : Jenkinsプロジェクト現状報告とこれから(基調講演)

Jenkisという一大開発プロジェクトに関する内容だった。

プロジェクトに関わっていない僕のようなエントリユーザにとって、このような概要を知ることができる内容はとても助かる。

・Jenkinsユーザは日々増えていますよー

・たくさんのビルドが日々走っていますよー

・もっとプロジェクトに関わっていきましょう

プラグイン開発とかやってみてね

みたいな内容だったと思う。

 

satta-2 : Jenkinsによる自動受け入れテストから継続的デリバリーまで

LinuxCon2012Tokyo以来の英語公演でびびった。いやタイムテーブル読めば分かるんだけど。

でも左スクリーンに逐次日本語で抄録を作ってくれたから分かりやすかったです。運営の人ありがとうございます。

講演者はJenkins : The Definitive Guidsの著者でした。買っていってサイン貰えばよかった。

価値あるプロダクトを提供するストーリの中で、Jenkinsを如何にして活用するか。

つまり、受け入れテストまでを含めたトータルの中で継続的に要求品質を満たすコードを出荷するには、受け入れテストまでを自動的にする必要がある。

常にリリース可能なバイナリを生成するために、Jenkinsを軸にした開発が重要。

このとき、Jenkinsはとにかく早く実行し、早くフィードバックを得ることが大切である。

継続的デリバリのプラクティスとしてお勧めなのは、Mavenのリリースプラグインのような人間が決めたタイミングでリリース候補バイナリを生成するのではなく、毎回コードをチェックイン→テスト→スナップショットビルド作成→受け入れテスト→コードメトリクス測定→リリース候補作成 までを行うことらしい。

または、常にスナップショットを作り続けるが、これと決めたバージョンをリリースビルドにする方法。mvn version:set を使うらしい。

つまり、顧客にデリバリーされるコードがビジネスにおける価値を提供することを保証するテストを自動化すると捗りますよ、ということだと思う。

 

satta-3 : 飛行機を飛ばしながら治す方法教えます : JenkinsとGerritによる継続的デプロイメントの実践

講師は @jenkinsci を運用しているらしい。でも僕は @jenkinsci を知らなかった。

内容は、毎日に近い間隔でデプロイメントを実現するには。

もちろんJenkinsを使うし開発プロセスを自動化するんだけど、人の手が入るプロセスはどうするか。(QAチーム?)

印象に残ったのは、"Manually Automated"というコンセプト。コードレビューのような、人の手が入り定量的な測定が難しいプロセスも生産ラインに組み込み自働化するようにしてやれば、Jenkinsの効果を引き出しやすいんだと思う。工業製品みたい。

GerritやOpenStack/jCloudsについての話もあったけど、その製品自体がよくわからないので話についていけなかった。

 

S406-4 : マルチステージ型継続的インテグレーションのすすめ(スポンサーセッション : テクマトリックス)

マルチステージって例えば運用サーバがDevelopment,Staging,Productionみたいに複数あってそれら複数のリソースをどうCIの中で活用するか、みたいな話だと想像していたけど、違った。

つまり、各開発チームで異なる成熟度のプロジェクトを統合するときの問題を、Jenkinsでどう解決するか。

マルチステージとは、ソフトウェア開発プロセスの成熟度段階のことだった。

採り上げられたのは、各チームの開発成果物を結合するタイミングでCIを導入した事例。

結合ビルドのみに導入したCIの副作用として、結合できるレベルに達していないソースコードが構成管理下にあることに起因するビルドエラーが頻繁に起き、しかもその影響が他チームにまで広範に及んだらしい。

改善策として現状を把握し問題を切り分け、モジュール構成や開発プロセスを見直すアプローチを取ったそうで、その時にJenkinsとかが有効に使えた(?)。

そして出た結論が、各開発チームのソフトウェア的な成熟に応じて、段階的(マルチステージ)に構成された継続的インテグレーションを適用する(し続ける)ことが有効だということ。これをマルチステージ型継続的インテグレーションと呼んだそうな。

マルチステージ型継続的インテグレーションには、ビルド失敗時の影響を小さくする、各チームの成熟度に応じた適切なフィードバックをすることができる、といったメリットがある。

その他のアプローチには、例えば「Googleバグ予測アルゴリズムによってピックアップされたコードを重点的にレビューする」といったものがあり、なかなか有効らしい。

あと、デモンストレーションで自社製品をさり気なくアピールするプレゼン手腕に地味に感動した。

最後のQAによると、今回話題に上がったテクマトリックス社製品の最小構成は、軽自動車くらいの費用で導入できるらしい。

分野違いだけど昔組み込み展示会に行った時に欲しくて欲しくて顧問の先生に買ってくれって頼んだ(Rejectされたけど)某I社製Rhaps◯dy(MDDツール)よりも安い。ステマじゃないよ!

 

satta-5 : 毎日が憧れの新築、反復可能なデリバリーによる常時新築システム

インフラ周りの話。PaaSバックエンドシステムを効率良く構築し管理するには〜みたいな。

コンビニで菓子パン食べてたら面白そうなところを聞き逃してしまってよくわからなかった。

 

⑥satta-6 : LT大会(オフレコってことになってるらしいし内容書いても良いのだろうか......?)

久々のLT。はじめからドラが大活躍していた。

そして面白い。

運用でJenkinsを使う話が一番印象に残った。

僕が最近いじっているcapistranoに関連するJenkins-Capistranoを作っている人が講演者だと最後に知ってマジでテンションが上った。

 

居酒屋北海道飯田橋店 : 懇親会

本会が大人数なら懇親会も大人数だった。まじびっくり。

「みなさんどんなことしてるんですか?」みたいな流れになって僕が学生であることが明らかになった後から、アドバイスをたくさん頂いた。曰く、

・社会人になるとプライベートの活動でも気を使うから大変(社名とかプライベートで書くコードとか)

・学生のうちにデタラメなソースコードGithubとかにアップしてボコボコにされた方がいい

・自分でクローンサービスでもいいからいちから立ちあげて運用すると、色々なこと(意味深)が分かる

らしい。社会人怖い。

あと、 学生のうちに外国行ったほうがいいよって言われた。

行ってみたいものだ。アメリカ。

 

-----その他の方の関連エントリ(見つけ次第更新)-----

Jenkinsユーザ・カンファレンス2012に参加してきた #juc2012 - Shinya's Daily Report

Jenkinsユーザ・カンファレンスで発表します!! - wadatkaの日記

JenkinsカンファレンスでLTしてきました #juc2012 - かおるんダイアリー

Jenkinsカンファレンス2012に行ってきたよ - mike、mikeなるままに

Jenkinsユーザ・カンファレンス2012 東京 - wasoban

AWSで実現するSeleniumテスト高速術 - 株式会社シャノン技術ブログ

「Jenkins ユーザ・カンファレンス 2012 東京 #juc2012」に参加してきた - みちしるべ