Shoeisha Technology Media

EnterpriseZine(エンタープライズジン)

EnterpriseZine(エンタープライズジン)

テーマ別に探す

第3回 ソフトウェア構成管理のカギを握るベースラインとビルド管理

  2009/06/24 09:00

ソフトウェア構成管理を実施する目的は、構成を再現することです。そのためには再現するための目印が必要になります。今回は、「ベースライン」の考え方と「ビルド管理」についてお話します。

はじめに

 前回は、ソフトウェア構成管理を実践するための現実的なアプローチ方法について述べました。

 さて、本来の目標である「目的に応じて、必要な構成を任意に再現する」ためには、自分達がどんな構成を必要としているかについて自覚しておく必要があります。どの時点におけるシステムの構成を再現したいのかが分かった上で、初めてどのバージョンを使えば良いかという話になるのですね。

 ソフトウェア構成管理においては、構成の識別について、「ベースライン」と「ビルド管理」という考え方でまとめています。今回はこの2つの概念について解説します。これらは、開発プロジェクトでの「ブランチ戦略」にも関わってくる重要な概念です。

ベースラインとは

 さて、再現したい構成とは何を指すのでしょうか? 前回のようなバグ改修の話であれば、直近にリリースされた構成などがそれにあたるでしょう。もちろん、必要な構成は、ソースコードだけではありません。上流工程の成果である要件や、設計書、設計モデルも変更される可能性がありますね。

 開発を開始するに当たっては、自分達がどの構成に対して作業を行うべきかを把握できている必要があるわけです。

上流工程の成果物と開発の関係
上流工程の成果物と開発の関係

 さて、「再現したい構成」は、開発のあらゆる工程において現れることでしょう。ソースコードの改修というレベルから、各工程間での作業の引き継ぎ(例えば、ビルド工程からテスト工程への引継ぎなど)というレベルまで、そのシチュエーションは多岐に渡ります。ここでは、将来的に再現したくなる可能性がある構成を「ベースライン」と呼びましょう。

ビルド成果物≒ベースライン

 なお、開発工程の中でも特に実装工程を完了し、ビルド成果物が作成された後は、 ベースライン≒ビルドと考えるのが一般的です。ビルドはソースコードの内容などが確定した状態で行うものです。特に意味も無くビルドしてみた、などというケースはあまりないでしょう。例えば、「機能追加プロジェクトで実装が完了した時点」などで行うはずです。すると、ビルドは将来的に再現したくなる可能性がありますね。

著者注

 ここでは、単純化するため「継続的インテグレーション(常時結合)については、触れないことにします。継続的インテグレーションを実践する場合は、より頻繁にビルドを行うことになります。この場合もベースラインとビルドの識別と管理は、同様に重要な概念となります。

 ビルドを行う際は、ビルドスクリプトを使用することが一般的ですから、どのバージョンのどのソースコードを使っているかを特定することも簡単です。そして、それらのソースコードに関連した設計書や設計モデル、要件も含まれています。まさにベースラインですね。

 ここで述べたベースラインの識別や管理に関する考え方は、第1回で説明したソフトウェア構成管理の要素のひとつである「ビルド管理」に含まれるものです。

※この続きは、会員の方のみお読みいただけます(登録無料)。


※この続きは、会員の方のみお読みいただけます(登録無料)。


著者プロフィール

  • 長沢 智治(ナガサワ トモハル)

    ソフトウェア開発業務改善のプリンシパル コンサルタント、ソリューション アーキテクトとして多くの多種多様なソフトウェア開発の現場のお手伝いを経験。現在は、マイクロソフトのエバンジェリストとして、特にチーム開発、開発プロセスやプラクティスの訴求を行うべく活動中。  ・ブログ「長沢智治のライフサイクル...

バックナンバー

連載:SEが知っておきたいソフトウェア構成管理きほんのき
All contents copyright © 2007-2019 Shoeisha Co., Ltd. All rights reserved. ver.1.5