連載
|
 |
|
|
|
●2.1 リポジトリ内は常にクリーンな状態に保つ
バージョン管理ソフトウェアを利用するうえで必ず守らないといけないことを1つ挙げるとすると、このリポジトリ内は常にクリーンな状態に保つということである。要するに、これは必ずビルドが通る状態のソース・コードをコミットする（バージョン管理ソフトウェアによってはチェックインと呼ぶ）という非常にシンプルなことなのだが、実際多くの現場で忘れ去られていることでもある。
なぜリポジトリ内をクリーンな状態に保つことが重要であるかというと、バージョン管理ソフトウェアに対してソース・コードをコミットするという行為は、そのバージョン管理ソフトウェアを利用しているほかの利用者に対してソース・コードを公開することを意味するからだ。ビルドが通らない状態のソース・コードをコミットするという行為はほかの利用者に対してビルドが通らない未完成のコードを利用させることになる。
また、未完成のソース・コードをコミットする行為はほかの利用者の開発をストップさせ、チームとしての生産性を大幅に低下させる原因にもなるし、ほかの利用者が未完成のソース・コードを修正してしまうと問題を複雑化させる原因にもなり得る。上記のような理由からも、リポジトリ内を常にクリーンな状態に保つことは開発チームの生産性や団結力を維持するうえでも非常に重要である。
では、このルールはどのようにすれば守れるだろうか？ マネージャが「リポジトリは常にクリーンな状態に保て！！」と叫ぶだけでは、実際にリポジトリ内が常にクリーンな状態に保たれているか確認することはできない。そこで重要になるのが常時結合というプラクティス（＝実践項目）である。
●2.2 バージョン管理と常時結合
常時結合とは、リポジトリ内のソース・コードを頻繁かつ継続的に結合させる（＝複数の開発者が作り出したソース・コードを結合してソフトウェアをコンパイル／ビルドする）アジャイル開発の現場でよく利用されているプラクティスである。
 |
| 図1 常時結合のイメージ |
図1で示すように、常時結合のプラクティスを導入することで、リポジトリ内にソース・コードがコミットされるたびに最新ソース・コードを結合させられるようになる（＝自動的にビルドが行われる）。つまり、そのタイミングで結合に失敗した場合は、関係者にメールで通知するかパトロール・ランプを赤く点灯させて視覚的に通知することで、リポジトリのクリーンな状態が破られたことを即座に知らせることができるわけだ。
また、常時結合のタイミングで単にビルドするだけでは、あくまでコンパイル・エラー・レベルの検証しか行うことができない。（もちろんそれだけでも何もしないよりははるかに効果的ではあるが）より常時結合を効果的にするには、テスト駆動開発でプログラミングを行い、その結果として作成される単体テスト・コードを常時結合と組み合わせることで、コンパイル・エラーだけでなくソフトウェアが動作レベルでも問題ないかを検証できる仕組みを作ることだ。
このように「バージョン管理＋常時結合＋テスト駆動開発」という3つがそろって初めて真の意味でリポジトリがクリーンな環境を構築できるのだ。さらには自動デプロイの環境もそろえることで、顧客に対して最新の動作するソフトウェアを常に提供することが可能となり、顧客からのフィードバックにも素早く対応できるようになる。
とはいえ、Subversionの導入と併せて、いきなりテスト駆動開発や自動デプロイも導入するのはかなりハードルが高いことも事実である。まずは、Subversionの導入とともに常時結合環境を構築し、ソース・コードがSubversionへコミットされるたびに自動的にビルドを行い、リポジトリが常にビルド可能であることを確認できる環境を構築するとよいだろう。常時結合とテスト駆動開発に関しては下記の記事を参考にしてほしい。
●2.3 ソース・コードの運用・保守まで考慮したリポジトリ構造を設計する
Subversionのガイドラインでは、リポジトリ内のフォルダ構造をどのように設計するかも重要となる。
通常のソフトウェア開発では「新機能の開発」と「既存機能の強化＆バグ修正」という2種類の異なる作業が混在した中で行われるのが普通だ。これら2つの異なる作業を同一のフォルダ上で行っていると、作業とその過程で発生するソース・コードが混在してしまう形になるため、例えばバージョン1.0.3に対するバグ修正のパッチを作成するといった作業が難しくなってしまう。
特に、開発標準フレームワークのように社内のほかのソフトウェア開発プロジェクトから共通ライブラリとして参照されるソフトウェアは、運用・保守と新機能開発を明確に分離することが重要である。そこで非常に重要となるのがメイン・ライン（trunk：木の幹＝主軸）とリリース・ブランチ（branch：木の枝＝分岐軸）という考え方である。
 |
| 図2 メイン・ラインとリリース・ブランチのイメージ |
図2で示すように、メイン・ライン（Subversionでは通常「trunk」というフォルダ名が使われる）とリリース・ブランチを利用することで、ソフトウェアの新機能開発はメイン・ライン上で行い、リリース以降の既存機能の強化やバグ修正作業は各リリース・ブランチ上で行うというように役割分担を明確にでき、バージョン1.0.3に対するバグ修正のパッチを作成する作業も容易になる。
ただし、メイン・ラインとリリース・ブランチを利用する場合、マージ（＝差異のある2つのファイルを統合すること）のタイミングに注意していただきたい。これは、メイン・ラインとリリース・ブランチをマージせずに利用し続けると、バージョン1.0.3で修正したはずのバグが、バージョン1.1.0で修正されずにそのまま残っているという事態に陥ってしまうからだ。
 |
| 図3 メイン・ラインとリリース・ブランチのマージ |
図3のように、リリース・ブランチ上で新しいバージョンがリリースされるタイミングでメイン・ラインに対してマージ作業を行うことで、定期的にメイン・ラインとリリース・ブランチの同期を取ることができる。
ではメイン・ラインとリリース・ブランチ以外にリポジトリ構造で考慮する点はないだろうか。
リポジトリ構造を設計するうえでもう1つ注意しなければならない点は、ソフトウェアのソース・コードと同期を取る必要があるものは、できる限りひとまとめにしておくということである。例えばソース・コードと同期を取る必要があるものの中で、特に同期が欠かせないものとして下記の2つを挙げることができる。
- DBスキーマとマスタ系データ
- ユーザー・ドキュメント
データベースの構造を定義したDBスキーマはソース・コードと密接な関係を持つので、同じバージョンのものを利用できる形で設計することが重要である。そうしないとDB管理者がDBスキーマに変更を加えた途端にソース・コードとのバージョンが一致しなくなり、ソフトウェアが動かなくなってしまうという事態に陥りかねない。
また、マスタ系データ（＝ソフトウェアを実行するのに必要な最低限のデータ)もバージョン管理しておけば、すぐに動作するソフトウェアをバージョン管理ソフトウェアから簡単に作成可能になる。
ユーザー・ドキュメントとは、ユーザー・マニュアルや運用手順書などで、これらはソフトウェアのバージョンと一致させる必要があるものが多いので、ソース・コードとひとまとめにしておくべきだ。これはソフトウェア開発で必要となるすべてのドキュメントをSubversion内に格納するという意味ではない。そのソフトウェアを運用するうえでバージョンが一致していないと困る必要最低限のドキュメントを格納するとよいだろう。
ここまでで説明した内容をSubversionで実現したリポジトリ構造の例を図4に示す。
 |
| 図4 運用･保守を考慮したリポジトリ構造の例 |
メイン・ライン（trunk）内に、ソース・コード（src）とDBスキーマ（db）、ユーザー・ドキュメント（docs）というフォルダが配置されている。
また、リリース・ブランチ（branches）内にはリリースしたバージョン番号ごとに「REL-1.0」「REL-1.1」というフォルダが作成されている。「REL-1.0」はバージョン番号を含めたフォルダ名であり、バージョン1.0.X系のリリース・ブランチであることを意味している。
リポジトリ構造を決める際には、バージョン番号を決めるルールも定めるとよいだろう（一般的には、既存機能の強化やバグ修正は「1.0.0」→「1.0.1」（＝＜メジャー・バージョン番号＞.＜マイナー・バージョン番号＞.＜リビジョン番号＞の形式）というようにリビジョン番号を上げ、新機能のリリースは「1.0」→「1.1」という形でマイナー・バージョン番号を上げる）。各リリース・ブランチ内のフォルダ構成は「trunk」と同じだ。
以上のようにリポジトリを利用するうえで必要なガイドラインを定めることで、ソフトウェア構成管理をより円滑に実施できるようになる。
それでは、リポジトリ利用ガイドラインの必要性を痛感した中村君と玉田君のその後の開発シーンを追ってみよう。
 |
 |
| INDEX | ||
| ［連載］オープンソースで始めるバージョン管理＆タスク管理 | ||
| 第2回 正しいバージョン管理でさらにイケてる.NET開発 | ||
| 1．Subversion利用でもまだまだイケテナイ開発シーン | ||
 |
2．リポジトリ利用ガイドラインの策定 | |
| 3．リポジトリ利用ガイドラインでイケテル開発シーン | ||
 |
||
 |
「オープンソースで始めるバージョン管理＆タスク管理」 |
- 第2回 簡潔なコーディングのために （2017/7/26）
ラムダ式で記述できるメンバの増加、throw式、out変数、タプルなど、C# 7には以前よりもコードを簡潔に記述できるような機能が導入されている - 第1回 Visual Studio Codeデバッグの基礎知識 （2017/7/21）
Node.jsプログラムをデバッグしながら、Visual Studio Codeに統合されているデバッグ機能の基本の「キ」をマスターしよう - 第1回 明瞭なコーディングのために （2017/7/19）
C# 7で追加された新機能の中から、「数値リテラル構文の改善」と「ローカル関数」を紹介する。これらは分かりやすいコードを記述するのに使える - Presentation Translator （2017/7/18）
Presentation TranslatorはPowerPoint用のアドイン。プレゼンテーション時の字幕の付加や、多言語での質疑応答、スライドの翻訳を行える
 |
|
|
|
|
