身を守るための最低限のビルド手順

継続的インテグレーションとか、デイリービルドとか、そこまでやる時間やリソースが無い場合でも最低限守って欲しいリリース用のビルド手順について勝手に述べます。

もちろん、継続的インテグレーションやデイリービルドができるのなら、そちらの方が望ましいですが、会社の宗教上の理由などによって禁止されていたりする場合もあるので、そういった場合のためになにかしらの参考になれば幸いです。

デイリービルドやインテグレーションビルドについて聞いたことがなければ、以下のページを参考にしてください。

特に「\¬ŠÇ—@ŽÀ‘H“ü–å@‘æ1Í \¬ŠÇ—“ü–å@‚Í‚¶‚ß‚É」はボリュームがありますが超重要です。
実践的な内容で、SubVersionによるバージョン管理、ブランチのさせかたなどについても述べられており、ソフトウェアエンジニアやプログラマならば読んでおいて損はないと思います。そちらを読んでもらえれば、あまりこちらで参考にすることは無いかもしれません。

手順

コミット漏れがないか確認する
ビルドを開始する前にリリースビルド用のタグ/ラベルを付ける
リリースビルド用のタグを元にクリーンなディレクトリへチェックアウトする
ビルドする
正常にビルドできたらテストする
テストが全て問題無く終わった後にタグ/ラベルを付け、ブランチを作る

1.コミット漏れがないか確認する

リリース用のバイナリをテストしてみてから、「あ、あの修正を入れ忘れていた！orz」という事態を防ぐためです。
確実性を高めるため、メールによる通知ではなく各担当者のところを回って確認した方が良いでしょう。

2.ビルドを開始する前にリリースビルド用のタグ/ラベルを付ける

ビルド開始の時点でのソースコードを取り出せるようにするため。
このときラベル、タグの命名規則を明確にしておくと良いでしょう。

バージョン番号
日付
リリース番号
リリースビルドかどうか

などを命名規則にいれると良いでしょう。
\¬ŠÇ—@ŽÀ‘H“ü–å@‘æ3Í SubversionƒxƒXƒgƒvƒ‰ƒNƒeƒBƒX@Œp‘±“IƒCƒ“ƒeƒOƒŒ[ƒVƒ‡ƒ“のバージョン番号の付け方などが参考になります。

3.リリースビルド用のタグを元にクリーンなディレクトリへチェックアウトする

「ビルド日付+連番」や「ビルド年月日時分秒」などのようなフォルダを作成し、その中へ最新のソースコードをチェックアウトしビルドを行います。
古いバイナリやソース、ライブラリなどが混入することを防ぐためです。
ディスク容量がもったいないとかいって、前回コンパイルした環境を使わない。

ビルドに必要になるライブラリなどの扱いについて

可能なら、リポジトリにライブラリフォルダを用意して、そこに突っ込んでおくと良いでしょう。
理由：だれがビルドしても、いつビルドしても同じ結果にするため。

たとえば、それぞれ別のバージョンのライブラリをダウンロードして使っていて、ビルドした人によって挙動が違うという事を防ぐ、あるいは、かなり古いライブラリがダウンロードできなくなっていて、ビルドできなくなってしまったという事を防ぐ（ごくごく希だけど。）

4.ビルドする

もちろん自動化しておきましょう。
理由：だれがビルドしても、いつビルドしても同じ結果にするため。

5.正常にビルドできたらテストする

ビルドが正常に終わっただけではビルドは完了していません。テストが必要です。
リグレッションテスト(回帰テスト)が自動的に行われるようにするのが理想ですが、自動化できていない場合でも、最低限ビルドで新規に追加した機能や修正したバグがちゃんと修正されているか程度の確認はしよう。

6.テストが全て問題無く終わった後にタグ/ラベルを付け、ブランチを作る

テストが完了しており、リリース可能であることを示すためです。
もちろんテストに失敗したらこのタグは付けません。
テストが完了している事がはっきりと分かるようなタグ/ラベルを付けると良いでしょう。
この際に生成されたバイナリなどをリポジトリにコミットするかどうかは自由に決めて良いです。
コミットしない場合は、バグの再現を確認する際、同一のバイナリが必要になる事があるため。、リポジトリのどのタグやラベルにどのバイナリが対応するか分かるようにしてアーカイブしておくと良いでしょう。

その他

本章では、リリース作業の自動化を説明しました。
自動化するうえで大切なことは、「誰でもいつでも常に同じリリース作業を再現できるようにすること」と、「どこまでを自動化するのかをよく検討すること」です。リリースのタグ付けやビルドは人が行うことが重要であれば、配備や配布用アーカイブの作成のみを自動化すればよいでしょう。

リリースのタグ付けなんかは手動でもいいですが、ビルド、配備やアーカイブの作成など手間のかかる部分は自動化すると良いでしょう。
なんにしても、「誰でもいつでも常に同じリリース作業を再現出来るようにする」というのは重要です。

実際の手順書を作る際は、手順書の鉄則 - Sacrificed & Exploitedも参考になるかもしれません。