第1章
構成管理入門 　

第2章
Subversionによるバージョン管理入門

第3章
Subversionベストプラクティス

第4章
Maven2によるビルド入門

第5章
Maven2ベストプラクティスリリースの自動化

第6章
リリースの自動化

Appendix
Maven 2はまり道


※WEB+DB PRESS Vol.39掲載の記事を載せています。

第3章　Subversionベストプラクティス

Authors:YOSHIHARA Hidehiko

継続的インテグレーション

リリースが無事終わり、一時の平穏な時間が流れる開発ルームで、一人ディスプレイに向かうO先輩の姿がありました。
その数日後、いつもの慌ただしさを取り戻した開発チームの中に、O先輩の姿はありません。
K太●O先輩、もとの部署に戻っても元気にやってるかなあ。まだ、いろいろと聞きたいことがあったんですけど。
M子●そうね、がんばってると思うよ。私たちもいつまでもO先輩に頼ってばかりじゃいられないわね。ところで、近ごろ夜遅くに定期的にテストをやって、その結果をメールで通知しているようだけど、まさかK太君じゃないわよね？
K太●僕はてっきりM子先輩かと。ちなみに今朝のメールにエラーが発生していることが書かれていたので、そのコードラインをチェックアウトしてテストを行ったら、同じエラーが出ました。どうやらマージ漏れのようだったので、すぐに対応しました。
M子●あらっ？O先輩からメールが届いてる。

【Oのメール】
Continuum（コンティニューム）をインストールしておいたこと伝えるのを忘れていました。 今朝届いたメールは、Continuumがユニットテストに失敗したことを通知してくれています。Continuumはコードラインが確実にビルドできるかどうかを、定期的にビルドしてテストしてくれるツールです。テストを自動化してもっと楽しちゃいましょう。

Continuumの詳しい情報は第5章を見てください。

Continuumで継続的にビルドとテスト

メインラインのように常に安定していることが求められるコードラインを維持するためには、定期的にビルドとテストを行うことが有効です。
この継続的ビルドと継続的テストもリリースと同じように、正確に同じことを行わなければいけません。また、このような作業はコードラインが頻繁に変更されている時間を避けて行う必要があります。 つまり、作業と時間の「自動化」が必要とされます。Continuumは、決まった時間に自動的にMaven 2を実行することで、継続的インテグレーションを実現してくれます。

COLUMN　Subversionプロジェクトのリポジトリ運用

プログラミング上達の秘訣は、多くのプログラムを参考にして自分で実際に試してみることです。構成管 理についても同じことが言えるでしょう。
ここではSubversionプロジェクトのリポジトリが実際にどのように運用されているのかを見ていきます。 オープンソースのプロジェクトならば簡単にリポジトリをのぞくことができるので、そこに詰め込まれた達人たちのノウハウ(注a)を目一杯吸収して、よりよい構成管理の糧にしましょう。
なお、Subversionのリポジトリ以外にも、有名どころのプロジェクトからはリポジトリの運用について学 べるところが多いと思います。リポジトリ運用の正解は1つではありません。ぜひ、さまざまなリポジトリをのぞき見して、効果的なリポジトリの運用を身に着けていきましょう。

●Subversionのリポジトリ
Subversionプロジェクトでは、もちろんSCMにはSubversionを利用しています。 Subversionプロジェクトのリポジトリはしっかりとしたポリシーに基づいて運用されており、そのポリシー やノウハウは「Subversionによるバージョン管理」というドキュメント(注b)にまとめられています。
また、「ハッカーの心得」というドキュメント(注c)も用意されていて、開発時の規約類(注d)はここに網羅されています。その一部にリポジトリ運用に間する記載があるので、その内容をおおまかに説明していきます。
リポジトリ注eに接続し、構造（図a）を確認しながら読んでみてください。

●リリースの手順とtrunkの扱い
Subversionプロジェクトでは、新しい開発はいつでもtrunkを使用します。また、リリース用ブランチからバグフィックスなどの修正がtrunkにマージされることもあります。
リリースのための手順は、まず最新のtrunk から「A.B.x」というリリース用ブランチを作ることです。 そこからそのブランチを安定させていき、十分に安定した時点で「A.B.0」というタグをつけてリリースしま す。非安定版をリリースしたいときには「1.3.7-rc1」のように、「alphaN」「betaN」「rcN」をリリース番 号のうしろに付けることが決められています。そのあとのバグフィックスはブランチ「A.B.x」に対して行い、リリースの時点で「A.B.1」のようなタグをつけてリリースします。

注a）これらのプロジェクトはコーディングルールもしっかりしてたりするのでそのへんも参考にしてください。
注b）http://svnbook.red-bean.com/ リポジトリ管理のバイブルです。量は多めですがぜひ読んでみてください。
注c）\http://subversion.tigris.org/hacking.html
注d）コーディングの前にテストを書け！（Writing test cases before code）なんてのもありますね。
注e）http://svn.collab.net/respos/svn

●リリース番号の採番
Subversionプロジェクトでは、リリース番号の採番方法にもポリシーが定められています(注f)。基本的には、APR（Apache Portable Runtime）(注g) のガイドラインに則って、

MAJOR.MINOR.PATCH

というリリース番号を使用しています。たとえば「1.4.3」なら、「メジャーバージョン 1、マイナーバージョン4、パッチバージョン3」となります。
概略になりますが、基本的には次のルールで運用されています。
非常にオーソドックスなやりかたですので、自分のプロジェクトのバージョンを決めるときにはぜひ参考にしたいところです。
また、Subversionはクライアント／サーバ型のアプリケーションですので、バージョンの違いによるクラ イアントとサーバ間の互換性を明確にするため、先述のAPR のガイドラインに則った部分に加えて、Subversionプロジェクト独自の拡張があります。
それは大雑把に言うと、「同じMAJORバージョンの系列（つまり、MINORバージョンやPATCHバージョンが上がったとき）では、クライアント／サーバ間プロトコルの互換性を決して損なってはいけない」ということです。
とはいえ、新機能が追加されたときなどは相手のクライアントやサーバが古いと動作できない場合もあります。そのときは、なんらかの対処ができるようにエラーであることを通知することが決められています。つまり、MAJORバージョンが変わらないときにはまったく通信できなくなってしまうことがないようにするための規約です。
このようなモジュール間の互換性に対する考え方は、1つのプロジェクトをいくつかのサブプロジェクトに分割して開発する大規模なプロジェクトでも有効なのではないでしょうか。
図a Subversionのリポジトリ

注f）http://subversion.tigris.org/hacking.html#release-numbering
注g）http://apr.apache.org/ Apache HTTP Server 2.x系でプラットフォームに依存する部分を吸収するために用意されたライブラリです。 現在はHTTP Server以外でも使用されていて、SubversionもAPRを利用するアプリケーションの1つです。プラットフォームへの依存をできるだけ少なくして、ソースコードのポータビリティを上げるのが目的のようです。

[Backlog] - Subversion -