第3章 Subversionベストプラクティス
Authors:YOSHIHARA Hidehiko
M子●K太君、FUKUOKAブランチの結合テストが通らなくなったみたいよ。K太君がコミットしてからダメみたいだけど結合テストはやったの？
K太●え？M子先輩、結合テストやってからコミットしてるんですか？
M子●当たり前でしょう。まさか、テストが正常に通らなかったものをリリースしてないでしょうね。
K太●そんなことはしませんよ。でもFUKUOKAブランチは、新バージョン開発用でしょう。コミットする前に単体テストは通してますけど、結合テストまでやっている暇はないですよ。
O先輩●おやおや、どうやら2人ともコードラインに対する認識が違うみたいだ。コードラインの性格を把握していないようだね。
M子●コードラインの性格ですか？
O先輩●ルールみたいなものかな。たとえば、単にコンパイルが通っただけでもコミットできるようにして
おくのかとか、コミットする前にテストのどこまでは通しておく必要があるのかとか。ほかにも、どの時点
でチェックアウトすれば問題ないのかや、そもそもこのコードラインはどういったことに使われるのか、いつ終了するのかなどの基本的なことも決めないとね。こういったことを、コードラインごとに決めてる？
M子●コードラインの目的はFUKUOKAという名前でわかると思います。期日は決めてないけど。あと、
テストが用意されているんだったらそれを通すのは当たり前のことですよね。
O先輩●そうだね。コードラインに付いている名前はなかなかわかりやすくてよいね。だけど、各コードラインの品質はバラバラみたいだね。取り決めたうえでバラバラならいいかもしれないけど、今みたいに同じコードラインに対してM子ちゃんは結合テストまでやってからコミットしてるけど、K太君は単体テストまでしかやっていないというのは問題かもしれないね。
M子●取り決めは、ホワイトボードやWikiに書いてみんなに共有できるようにしておいたらよさそうですね。
O先輩●うん、ルールだからみんなが理解して、ちゃんと守るように周知しないとね。
K太●何か面倒ですね。
O先輩●確かに面倒なことかもしれない。そこはコードラインの様子を見て臨機応変に見直しをかけても
問題ないだろうし、取り決めが開発者の負担になってコミットを渋るようになっては本末転倒だから気をつけたほうがよいね。
M子●そういえば、K太君この前コンパイルもできないソースコードをコミットしてたでしょう。
O先輩●それは、問題外だ。
コードラインの目的は「新規開発用」「特定先リリース用」「障害対応用」など多種多様です。その目的によって求められる品質も異なります。
たとえば、メインラインからチェックアウトしたソースコードはちゃんとビルドできてユニットテストが通ることが好ましいでしょう。
リリース用のコードラインで結合テストが通らないなどは大問題です。逆に、自分用に作成したブランチはコンパイルが通るだけでも十分かもしれません。コードラインに求められる品質を保つためには、コミットを行う前にソースコードレビューやテストを行ったり、継続的にビルドを行ったりといろいろな決めごとが必要になるでしょう。
当たり前のことかもしれませんが、コードラインの目的も明確にしておくことも重要です。
このようなコードラインに定める約束事を「コードラインポリシー」と呼び、コードラインに携わる人たちは守っていく必要があります。
M子ちゃんが行ったコードラインの目的を名称に使用することは、比較的簡単で有効な手段です
（Subversionではメインラインに「trunk」と名づけることが推奨されています）。そのほかの事項につい
ては、極力一目見てわかるぐらいの分量に明文化して、共有できる環境に保持したほうが良いでしょう。
以下に、コードラインポリシーの例を挙げます。
■コミット条件
コミットを行うために事前に満たしておかなければいけない条件を定めます。例としてはコードレビューや、事前テストが挙げられます。テスト内容も、ユニットテストや結合テスト、ブラックボックステストなど、コードラインによってカバレッジを調節しましょう。
■コメント
インポートやコミット時にコメントを残すことができます。タグ付けされていないリビジョンについてログを参照する際、このコメントが非常に役に立ちます。
たとえば、BTS（バグ追跡システム）に管理されている障害に対応したコミットのコメントには、BTSで参照されるIDやURLなどが有益な情報です。
■アクセス制限
コードラインに対してアクセス制限を設けます。
ユーザのコミットや参照可否についての権限だったり、コミットが可能な期間や時刻が該当します。
Subversionでは、ユーザごとにコミットや参照可否についての制限を、Apacheの設定ファイルで制御できます。
■チェックアウト条件
チェックアウトが行えるコードラインや、そのチェックアウトを行うタイミングを取り決めます。
電話で事前確認をしてからチェックアウト行ったり、チェックアウト用のタグからチェックアウトを行うなど、不用意にチェックアウトを起こさせたくない場合には条件を設けるとよいでしょう。
■責任者
コードラインに対して責任者を設けることは、SCMでは比較的多く見られます。責任者は開発者でない場合もあります。
例としてコミットを許可する承認者などが挙げられます。過去に筆者が携わったプロジェクトでは、マージ作業の責任者が指名されていて、コードライン間のマージは責任者が行っていました。
特に、Maven 2で使用するpom.xmlのような、プロジェクトの基板を構成するようなファイルには編集責任者を決めておいたほうが好ましいでしょう。
■タグ／ブランチの付け方
タグとブランチの作成は、いつでも誰でも簡単に行うことができるため、作成用途や命名規則についての取り決めを行っておくことが、コードラインを管理する上では非常に有効です。
特にタグは、コードラインのマーク付け（お手軽コピー）として乱用される傾向が見られますので、たとえば以下のような基準を設けておきましょう。
- リリースを行った状態を保持するタグ
- チェックアウトが可能なリビジョンを示すタグ
- マージや大きな変更が起きた節目を表すタグ
■更新・マージ
更新に対してはあえて取り決めを行う必要はないと思いますが（最低でも、コミット前に更新は必要でしょう）、マージに関しては、マージが可能である状態やマージ中であることを把握できる手段を設け、開発チームの中で取り決めた条件下で行うようにしましょう。また、マージ後にタグを作成してマージが行われた事を判断できるようにしておきましょう。
■継続的作業
コードラインに対して、「継続的ビルドリリース」や「継続的テスト」など、定期的に行われる作業が存在することを明確にします。
◆ ◆ ◆
重要なのは、コードラインポリシーは、開発効率を損ねるようなものにしないことです。
事前テストなどはそれだけで作業負荷がかかるため面倒で、開発スピードが低下してしまいます。コードラインポリシーは開発リズムを調節する重要な役割も持っています。その都度見直しを計りましょう。
![[Backlog] - Subversion -](../images/ad-backlog-svn.giff)