第3章 Subversionベストプラクティス
Authors:YOSHIHARA Hidehiko
リリースはソフトウェア開発の大一番の作業です。
ここで失敗したらすべてが水の泡と化します。また、リリースを行ったあとも発生した障害対応のために
その状態しっかりと管理しておく必要性があるため、SCMの中でも重要な位置を占めています。
毎回同じことを正確に繰り返さなければいけないリリースという負荷の高い作業には、バージョン管理とビルドツールを有効に活用しましょう。
O先輩●いよいよリリースだね。
M子●はい、マージや最終テストなど、リリースするためにやらなければならないことがたくさんあります。まずは、コミットの期限を決めないと。
O先輩●もしかして、「期限」ってコミットに制限をかけることを…
と、M子ちゃんに尋ねようとしたO先輩を制して、横から慌ててK太君が割り込んできました。
K太●えー！どれくらいコミットできなくなるんですか？次のリリース分の開発も行っているから止めたくないんですよね。
M子●リリース作業のテストに問題を起こすかもしれないから、今回のリリースに関係ない分をコミット
するのは控えてほしいわ。
K太●でも、リリースが終わるまで待っていたら、今開発している分が次のリリースに間に合わなくなってしまいますよ。
そんな2人のやりとりに、O先輩が毅然とした態度でアドバイスをしました。
O先輩●並行して作業を行いたいときこそブランチを有効に活用しないといけないよ。リリース用のブランチを作成して、そっちでリリース作業をやるようにしなさい。
M子●ブランチヲ作成したいのは山々なのですが、リリース用のブランチで対応した修正をメインラインに
反映したり、その逆の場合も考えられますよね。
O先輩●確かにそれはあるけど、いつ終わるかわからないリリース作業のために開発を止めるほうが効率が悪そうだし、開発のリズムを乱すことにもなるから、好ましいものではないよね。あと、リリース用のブランチを作成しておいたほうがリリース後の対応がやりやすくなるよ。
リリースのタイミングは、このプロジェクトをずっと見てきたM子ちゃんが一番よくわかるだろうから、大変だけどがんばって。
次の日の昼一番にメインラインからリリース用ブランチを作成し、リリース作業が始まりました。
コードラインからリリース作業を行うためには、コードラインを安定させる必要があります。最終テスト中にソースコードが変更されてしまっては大変です。
M子ちゃんがやろうとしたようにリリース分のコミット受付時間を取り決めて、リリースが終わるまでコードラインを凍結することが確実ですが、リリースと無関係の機能の開発や次期リリースに向けての開発が控えているような場合に、リリース作業のためにコードラインを止めることは効率的ではありません。
メインラインからリリース用のブランチ（これを「リリースライン」と呼びます）を作成することで、開発を止めることなくリリースを並行して行うことができます。（図4）
ただし、ブランチの作成にはマージがつきものです。リリースラインの作成が早過ぎるとマージの回数も増えてしまいますし、かといって遅過ぎるとリリース作業が詰まってしまう恐れがあります。コードラインの安定度を見極めてブランチの作成を行ってください。
通常、リリースを行ったあとも障害対応や機能追加などで開発を継続し続けることになります。メインラインの最新版から、リリース後対応用コードラインをその都度作成できればよいのですが、リリース用に個別に変更を行っている場合（ほとんどがそうだと思います）、それをまた個別に反映しなおすのも手間がかかります。
このような問題を解決するために、リリース時の状態を保持しておいてメインラインとは別にリリース後対応用のコードラインを保守して行く必要があります。（図5）
リリースラインの作成を行っているなら、それをそのままリリース後対応用のコードラインとして使用してください。もしリリースラインの作成を行っていないなら、リリース時の状態がわかるようにタグを付けて必要なときにそのタグからブランチを作成してリリース後対応用のコードラインを作成してください。
![[Backlog] - Subversion -](../images/ad-backlog-svn.gif)