Jenkins勉強会のスタッフ視点からの反省

Jenkins

この前のJenkins勉強会のレポートも無事掲載されたということで、反省すべき点を忘れないうちにつづっておきます。

分割募集の意図を伝えきれていなかった

一番がこれ。「1時間で40人の1次募集枠が埋まってしまう」レベルだったので、告知のタイミングでたまたまチェックできなかった人にもできるだけチャンスを与えようとして、1,2,3次と分割募集したのですが、その意図を明確に伝えきれていませんでした。なので、どこに応募すればいいか戸惑った方もといたかと思います。

この辺、キャンセル待ちとかは使う告知サイトにもよると思うので、ある程度吟味してから選択していきたいです。

色々見積もりが甘かった

  • 時間
  • お金
  • 当日タスク

とか。

当日タスクは先にある程度決めておかないと、土壇場では頼みにくい。みんな発表は聞きたいはずなので。

あと、自分が聞けないのは諦めた方がいいかなと思いました。どうせ、レポート書くときに一からじっくりUst聞き直すから、諦めて裏方に徹しまくったほうが無難かなと。

ビアバッシュはスタッフ側の負担がぼちぼち大きい

ビアバッシュするとなると、当然参加者全員から料金徴収する必要が出てきて、そしたらドタキャンの問題とか受付の負担が増えるとかもあるので。参加料無料だと、ドタキャンについてはそこまで考慮しなくていいんですけどね。

ただ、参加者にとっては、ビアバッシュは結構ありがたい仕組みですよね。安上がりで懇親会的なノリで皆と話せるし、時間もそんなに遅くならない。

なので、毎回は無理ですが年1ぐらいではやれたらなーと思いました。

デジカメ忘れたので、レポートに掲載する写真が少なくなった

タイトルで終わり。

ちょっと今回アップアップになってしまって、心の余裕が無くなってしまったのが申し訳ないです。スタッフ側に余裕がないと、参加者も楽しみにくいだろうし。

今度からは心に余裕を持つことを心がけて、発表者/会場提供者/参加者みなさんに感謝の気持ちを忘れないようにしたいと思います、まる。

http://3.bp.blogspot.com/_LM8HL3MnkQE/Szp6xofYNnI/AAAAAAAAC48/wyOyxnT_XDk/s320/%E6%84%9F%E8%AC%9D%E3%81%A3%EF%BC%81%E5%9C%A7%E5%80%92%E7%9A%84%E6%84%9F%E8%AC%9D.jpg

Jenkins本 & WEB+DB Press Vol.67 を献本いただきました！

Jenkins

レビューをさせてもらった経緯もあって、ついにねんがんのJenkins実践入門を献本してもらったぞ - @ikikko のはてなダイアリーに引き続いて2冊の献本をいただきました。オライリー様・技評様、ありがとうございます！書評遅くなってすいません...orz

Jenkins

一部では蛙本という愛称で知られている、Jenkins本です。

Jenkins

Jenkins

原著がPDFで無償提供されているので読んだことはあるのですが、翻訳版を読み返しても案の定細かいことはまったく覚えていませんでした。英語が全然苦なく読めるという一部の人以外にとっては、やはり日本語で読めるというのはとっかかりとして楽だと思います*1。

はじめの一歩でJavaの次にいきなりGitをインストールしてくださいとか、Mavenベースで説明されてるとかで、Jenkinsを最初に使う方が読むのはちょっとハードルが高いでしょう。ただ、「Jenkins実践入門」や「Jenkinsで始めるビルド職人入門」がAntベースだったので、Mavenをメインで使う方は参考になるかと思います。実は僕もあまりMavenベースでJenkinsを運用していないので、勉強になりました。

本書の内容をいきなり全部実践するのは難しいと思うので、一度目を通しておいてこんなときにはこんな手法が使えるんだよ的に使うのがいいのではないでしょうか。

また、日本語版だけの特典として、付録にPlay! Frameworkを題材にプラグイン開発の説明が付いています。ただ、僕のようなPlay弱者にとってはそのまま試すことができないので、ツライこともあるかもしれません。そんなときは、下記資料が参考になるかと思います。この辺は特定のモジュールに依存していないので、Jenkinsプラグイン開発に絞って学ぶことができます。（kiy0takaさんのは一部Twitterに依存してるところがあるけど）

WEB+DB Press Vol.67

今月号のWEB+DBの第1特集に、あの川口さんがJenkins特集を書いています。デブサミの発表でも語られていたそうですが、川口さん自身の口からJenkinsやCIへの思いを知れるというのは、それらを理解する上で重要なことだと思います。

WEB+DB PRESS Vol.67

WEB+DB PRESS Vol.67

特集の中身は、第1、2章でJenkinsについて簡単な紹介があった後に、後半ではJenkinsを使いこなす技が惜しげもなく紹介されています。プラグインの使い方の単純な説明や、単に手動ビルドを自動化への置き換えというだけでなく、Jenkinsを使ったからこそできることが色々と書かれています。

僕はどちらかというと、Jenkinsがなくても開発が進められるようにする方向に倒すことが多いんですよね。「基本的にビルドスクリプトで実装して、Jenkinsではそれを叩くようにする。普段はJenkins上から実行されるけど、いざとなればビルドスクリプトを直接実行することもできる」という方針。ただ、Jenkinsのプラグイン使えば楽にできることも、ビルドスクリプトで実装するのは面倒なことも多いんですよね。デプロイ関係とかレポート周りとか。

そこで、Jenkinsがあることを前提にできる環境ならば、Jenkinsにべったりで組んだ方が楽になる機会も多いかなと思いました。この辺はケースバイケースで考えていきたいです。

なお、これらの書籍はこの前のJenkins勉強会で、余興の一環として参加者にプレゼントさせていただきました。オライリー様・技評様においては、プレゼント用にも提供していただきありがとうございました。

*1:Jenkinsは進化も早いので、なるだけ本家英語版のドキュメントもしくはソースコードを読むにこしたことはないのですが

GradleでEclipseの設定をカスタマイズする

Gradle

2,3日前にMaven神が荒ぶっておられました。（この辺のやりとり興味あるのですが、どなたかTogetterしてないですかね？）

【追記】「mavenからgradleに移行する理由ってあるのかね」という流れだったようです。そこ見逃していました、すいません。

必須条件

  • Gradle 1.0-milestone-8 以上
    • GRADLE-2024 の対応が取り込まれている必要がある

設定方法

build.gradleに、以下（特に後半のwithPropertiesのところ）を追加してみてください。

apply plugin: 'java'
apply plugin: 'eclipse'

...

eclipse.jdt.file {
	withProperties { properties ->
		// 折り返す行数を120まで伸ばす
		properties.put('org.eclipse.jdt.core.formatter.lineSplit', '120')
	}
}

こんな感じで、Eclipse側の設定を追加できます。あとは、折り返しの行数以外の必要な設定も適宜追加してやればいいでしょう。

【追記】普通は一つ一つ設定するより、フォーマッタをファイルに落としておいて、それを読み込むことの方が多いでしょう。ファイルからフォーマッタの設定を読み込むには、以下のような形で実現できます。（例として、フォーマッタファイルはformatter.xmlとして保存されているものとする）

eclipse.jdt.file {
	withProperties { properties ->
		def formatter = new XmlSlurper().parse('formatter.xml')

		formatter.profile.setting.each {
			properties.put(it.@id as String, it.@value as String)
		}
	}
}

.projectや.classpath, .settings/org.eclipse.jdt.core.prefsは同じようなやり方で制御できます。が、それ以外で制御が必要なやつがある場合は、ちょっとやり方を変える必要があるかもしれません。あと、FindBugsとかCheckstyleとかはまた別の設定が必要になるけど、それは何とでも設定できるでしょう、多分。

大阪のJenkins勉強会で発表してきました

Jenkins

東京だと僕は話聞くより裏方に回る方が多いので、これに遠征して話してきました。主催の@さん・@さん、非常に広い会場をお貸しいただいたTIS株式会社様、平日の夜にも関わらず参加してくださったみなさん、ありがとうございます。

中規模プロジェクトでのJenkinsの運用を支える技術
View more presentations from ikikko

発表内容的には、「Jenkinsのプロジェクトがたくさんあるときの管理コストを減らす」という視点からでした。これはこれで面白いとは思うのですが、このテーマとは少しずれるので話さなかった話もいつかまとめて発表なり明文化して整理しておきたいです。

発表内容とはちょっとずれますが、「発表のテンポがよくて聴きやすい」という声があったのが嬉しかったです。致命的に滑舌が悪いのは自覚しているので、少しでもテンポよくするためにちょいちょい工夫してたのが多少なりとも効果あったのかなと。スライド4,5枚に1枚は画像のスライドを挟むようにしている*1のとか、ちょっとヒートアップして早口になってきたなと思ったら水を飲んでリセットするというのを意識して実践したのとか。

他の人の発表は、GerritとかEC2とかXFDとか、いずれ取り入れてみたいものばかりのデモでした。デモでやられると、やっぱいいなーって思いますよね。

懇親会では、久しぶりにほぼアウェイなところで、新鮮に話せました。発表時に伝えきれなかったことなどもあって、ちょい自分の話が多くなった感があるので、もうちょっとみんなの話を聞けるようにすればよかったなとは反省してます。あとは、kiy0taka さんとJenkinsの内部的な話ができたのも面白かったですね。Jenkins Tutorial Pluginをお待ちしています。

まとめると、テニスの王子様面白いですよねってことでいいですかね。早く天衣無縫の極みを開拓したいです。

*1:全部画像のスライドにしてもいいけど、画像探すのが若干面倒なのと、箇条書きというか文字として適度に説明が記載してあった方がスライド見ただけで分かりやすいっていうのがありまして。

HTTPアクセスを記録/再生してテスト時に使える、Betamaxを試してみたよ

Groovy

「初夢が別の人と結婚する夢だった」と妻に話したら、「私も別の人と結婚してる夢を見て、子供も産まれてた」と返されて負けた気がしたikikkoです。あけましておめでとうございます。今年もよろしくお願いします。

http://livedoor.blogimg.jp/pistolskate-moso/imgs/f/e/fe3c0a58.jpg

概要

Betamax - Record / playback testing proxyとは・・・うまく説明できる気がしないので、丸ごと引用してきます。

BetamaxはWebへのアクセスを記録して再生することのできるrecord/playback proxy です。

最 近 の ア プ リ ケ ー シ ョ ン は Twitter や Facebook な ど 外 部 のWebAPIと連携するものが多くなってきていますが、Betamaxを利用すると実際にWebAPI やWebサイトへのアクセスを行わずにアプリケーションのテストを行うことができます。

Betamax はHTTP リクエスト・レスポンスのペアを、HTTP リクエストの内容をキーとして「tape」というテキストファイル(YAML) に記録します。テストケースに対してtapeを指定してやることで、既に記録済みのHTTP リクエストに対してはtape の内容が再生されます。未記録のHTTPリクエストであれば、実際に得られたレスポンスをキャプチャしてtape に記録します。

http://grails.jp/g_mag_jp/file/gmagazine_4.pdf

Groovyカテゴリに入れてますが、JUnitをはじめとしたJavaオンリーでも多分使うことができます（未検証）。

もうちょっとちゃんとした説明は、下記を参考にしてください（説明されている内容はどちらも大体同じです）。

メリット

いくつか参考資料中でも述べられていますが、外部にアクセスにいかないので下記のようなメリットがあります。

  • オフラインでテスト実行できる
  • スローテスト問題を解決できる
  • （ネットワークや接続先での障害といった）外部環境の影響を受けにくい
  • 更新系APIでの副作用問題が起きない

また、通信データを加工できるので

  • レアケースを簡単に再現できる
  • （認証情報などの）共有するべきでない個人情報を除去した上で、データを共有できる

というのもあげられるでしょう。

外部APIを使ったテストには、ダミーのモックを使うという選択肢もあります。ただ、Betamaxでは実際の通信データを再利用するので、まるごとモックを用意するよりは信頼できるデータといえるでしょう。

サンプル

サンプルでは、Cacoo APIを使っています。具体的には、図の新規作成/コメントの追加をCacoo API経由で行い、そのレスポンスから最新のコメントを取得するものです。Cacoo APIを含んだコードでも、毎回外部（Cacoo）に接続しに行かずにテストします*1。

サンプルコードは、Githubの下記の場所に置いています。Gradleでプロジェクトを作成しておりGradle Wrapperも用意しているので、cloneして"./gradlew test"と入力すればサンプルを実行することができます（Groovy環境も必要ありません）。テスト実行後、"build/reports/tests/index.html"で実行結果や出力を確認できます。

解説

メインのコードは以下です。

Betamaxの設定は大きくわけて、下記の2点です。

  • @RuleにRecorderを設定する
  • 各テストケースに@Betamaxを指定する

まず、RuleにRecorderを設定します。これは、単純に宣言するだけで十分です。

// Betamaxを使用して、通信内容をtapeに記録/読込できるようにする
@Rule Recorder recorder = new Recorder()

@Betamaxでは、tapeの保存先を指定します。また、tapeから読み込むときの判定条件を「リクエストの（ホスト名+パス）が一致したとき」というように変更しています。デフォルトだとURI一致なのですが、今回はAPI Keyをクエリーストリングに含むのでURIが変わる可能性があったので、このようにしています。

// 保存先のtape名を指定, ホスト名/パスが一致した場合はtapeから読み込む（クエリは判定対象外）
@Betamax(tape="create diagram", match=[
	MatchRule.host,
	MatchRule.path
])
def "図の新規作成"() {
  ...
}
tapeの記録

通信内容をtapeに記録するために、初回はHTTP通信が発生します。記録された通信内容は、YAML形式で保存されます。以下のファイルが、tape内容です。

Cacoo APIを使う場合はAPI Keyが必要ですし、記録されたtapeにもAPI Keyも合わせて記録されています。ですが、push前に上記のtapeを直接編集して、API Keyの情報を除去しました。このように、一度tapeを作成してから、都合がいいようにデータを改ざんできるのもメリットの一つです。

tapeの再生

2回目以降は、作成されたtapeを元に通信が再生されます。以降はネットワークにつながっている必要がありません。また、API Keyを設定しておく必要もありません。

pushをしたものはすでにtapeの記録を行った状態なので、再生から実行することができます。

問題点・注意事項

HTTPSをサポートしていない

一番大きいのはHTTPSをまだサポートしていないということ。Issueとしてあがっているので認識はしていると思うのですが、いつサポートされるのかは分かりません。

これサポートされないと、多分厳しいよな・・・

HttpClientを使う場合は、Proxyの設定が必要

Betamaxでは、実行時にJavaのProxy設定をいじってBetamaxが起動しているサーバ（デフォルトではlocalhost, 5555）に向けます。ただ、HttpClientのデフォルト設定では、JavaのProxyの設定を参照しないようです。HttpClient（や内部でBetamaxを使っているHttpBuilder）でもBetamaxを使うために、ちょっと設定を追加する必要があります。サンプルコードではHttpBuilderを使っているので、それ用の設定も追加しています。

詳しくは、下記を参照してください。

公式サイトのドキュメントとリリース版のモジュールが一致していない

これにしばらくハマりました。ドイヒーですよね。

公式サイトにまだリリースされていない機能も書かれています。具体的には、betamax.propertiesというプロパティファイルでいくつか設定を変更できるのですが、これのignoreHosts/ignoreLocalhostが現在リリースバージョンの1.0には含まれていません。

他にもあるかもしれないので、注意しましょう。

どうでもいいですが、テニスの王子様って面白いですよね (・∀・)

*1:Backlogの方がAPI連携ネタとして実用的なことが多いので普段はBacklogを使ったサンプルが多いのですが、ちょいちょい問題があったので今回はCacoo APIを例にあげました。問題については後述します。

Shibuya.tracでJenkinsについて発表してきましたよ

Jenkins

先週金曜日に、Shibuya.trac 第13回勉強会でお話してきました。きれいな会場を提供してくださったパソナ様、発表を聞いてくださった参加者の皆様、ありがとうございます。

Jenkins実践入門のnext step
View more presentations from ikikko

発表のはじめに

  1. Jenkinsを知らない/使ったことがない人
  2. Jenkinsをちょっと使ったことがある人
  3. Jenkinsを実プロジェクトで使っている人

というようなアンケートをとったのですが、今回は2番目の層がターゲットでした。「色々Jenkinsの情報はあるけど、この辺を見ていけば効率よく情報収集できるよ」っていうのが、テーマです。Jenkinsをがっつり使い倒している人にとっては、ちょっと物足りなかったかもしれませんね。

Shibuya.tracなのにTracやBTSと絡めた話ができなかったのは、ちょっと残念でした。まあ、ネタを考える時間もなかったので、仕方ないということで。「何か小ネタを挟め」と上司からパワハラを受けたので、泣く泣くデスノートを挟んだのはナイショの話です・・・

次は年明けて2月に、大阪遠征してJenkins勉強会で発表させていただきます。今回はJenkinsだけではなかったので少し軽めのテーマだったのですが、大阪ではJenkins勉強会ということもあって運用事例も含めてちょっと踏み込んだ内容を話せればと思ってます。大阪近辺の方は、ぜひよろしくお願いします。

Groovy Eclipse Pluginのあれこれ

Groovy

この記事は、G* Advent Calendar 8日目の記事です。

http://atnd.org/event_images/0004/2777/g_ecosystem.001_original.jpg

最近Groovyを一番書いているエディタは、Jenkinsのスクリプトコンソールなikikkoです、こんにちは。Groovyはあまりコアな使い方はしていないので、ライトな記事でいかせていただきます。ということで、GroovyのEclipseプラグインについて。

Eclipseプラグイン

Groovy用のEclipseプラグイン、Groovy - Eclipse Pluginです。主な機能はこんな感じ。公式サイトから転載して、適当な日本語に訳してます。

そういや、Groovy-Eclipseプラグインの設定については、以前こんなのも書いてました。

リファクタリング

多分Eclipse JDTの最も優れている機能の一つであるリファクタリングのサポート。さすがにJDTほどではないですが、Groovyプラグインもちょいちょいサポートしています。

機能的には、

  • ローカル変数/メソッド/クラス/フィールドのリネーム
  • メソッド/ローカル変数/定数に抽出
  • スーパークラスにプルアップ/サブクラスにプッシュダウン

といった、まだまだ基本的な機能ばかり。

ただ、Ctrl+1(cmd+1)のquick fixがあまりサポートされてないのがちょっと残念。使う頻度の高いであろう変数名のリネームもquick fixではサポートされてなく、"コンテキストメニュー > Refactor > Rename"のように遷移しなければなりません*1。

Java<=>Groovy間でのリファクタリング

で、機能面が若干不足していることはとりあえず脇に置いておいて。

少し前にテストをプロダクトコードと別言語で書くことに関するTL - Togetterが話題になりました。（Javaに関しての）結論的な意見としては、大体↓な感じかなと。


ですが、Groovy EclipseならJava<=>Groovyの2言語間でリファクタリングが追随されるんです*2！これで、テストコードは気軽にGroovyで書きつつプロダクトコードはJavaで書いても、どちらでリファクタリングしてもちゃんと整合性が取れます。やったねたえちゃん！

https://cacoo.com/diagrams/EvOLBDFqjtfCszMe-35E79.png

ちなみに、他のIDEは試してません ｷﾘｯ。まあ、Groovyサポートが手厚いIntelliJとかなら、この辺よろしくやってくれるんじゃないかなと勝手に思っています。

それでは、みなさんよいGroovyライフを！

*1:ショートカットキーは割り当てられています

*2:環境によってはファイル名のリファクタリングがうまく効かなかったりするみたい。Eclipse本体/Pluginとも最新にしておけば多分大丈夫だとは思いますが、念のため確認しておいてね。