Jenkinsのリリースプロセス

Jenkinsのリリースプロセスが変わるようなのでメモしておく。あ、言うまでもないと思いますが僕がリリースマネジメントしているわけではなく、WikiやMLからの情報です。なので僕の英語力ではとっても不安ですw

Current state of Jenkinsのp10,p11にも情報あります。参考まで。

JenkinsはHudsonの時代からコミッタになる敷居が低く手を上げれば誰でもコミッタになれるというプロジェクトだった。
その影響もあってか開発も活発だったわけだが、これにはリグレッションという負の面もあった。

リグレッションなんてけしからんと言う人もいるかもしれないが、完璧なソフトウェアなどといったものは存在しない。
どうしてもバグを0にしたいなら、コード書くのを止めるしか無い。ステップ数が0のコードにバグなんて無いからね。

SIer的な対策だとレビューを入れるなどの関所を増やす方向になるだろう。たしかWebKitなんかはこの方式だったような。ていうかあそこはコミッタになる敷居も非常に高いらしい。

もちろんJenkinsプロジェクトではそんなことはしないわけだが、仮にやったとしたら品質面は上がるかもしれないが開発スピードが落ちるだろう。

Jenkinsプロジェクトでは、今までは週1回リリースブランチ作ってリリースするという方式だったため仮にリグレッションが発生してもすぐに修正版がデリバリーされた。

要はスピードを優先しているわけだ。開発者を潤沢に抱えているわけではないだろうからリリースマネジメントにあまり工数も割けないだろうし個人的にはこれでいいと思う。

そう思っていたのだが、やはり安定版が欲しいという声は多かったようでそれに向けて動いているようだ。

最近 http://jenkins-ci.org/ の右側に下記のようにRelease, RC, LTS(RC)の3つのタブが出来た。Releaseは今まで通りでRCはRelease Candidate、LTS(RC)のLTSはLong Term Supportの略である。

リリースプロセスについては下記に書かれている。

https://wiki.jenkins-ci.org/display/JENKINS/Release+Process

ブランチはmaster(開発の本線), rc(リリース候補), stable(安定版)の3つがメインとなっているようだ。詳細はhttps://github.com/jenkinsci/jenkins/networkを見ると良いかも。

週一でmasterからrcにブランチを切ってRelease Candidateをリリースする。これがトップページのRCタブに相当する。ここで問題無ければ正式リリースとなりReleaseタブのほうにアップされる。

stableブランチは安定版のためのブランチだ。ここでのリリース物がトップページのLTS(RC)タブに相当する。安定していたバージョンをピックアップして、そこからブランチを切って、masterのbugfixをbackportしているようだ。現状は1.409からブランチして[JENKINS-9367]をbackportしているようだ。4bfdb1eと8c8f4d2をcherry-pickしているね。バージョン番号は1.409.1, 1409.2のように上がっていきこのサイクルは3か月と書かれている。

OSSプロジェクトはどこもリリースマネジメントが大変だと思うが、どういうやり方をしようとしているのか観察するのは興味深い。