複数リリースを持つソフトウェアの構成管理課題

複数のプロジェクトで共通に利用するソフトウェア（フレームワークや共通ライブラリ）を管理する場合の構成管理上の課題を整理中です。解決手段の検討はまた別途・・・

想定ケース

• 最初のプロジェクトでは、共通ソフトウェアはアプリケーションと一体で開発・構成管理されていました。
• 最初のプロジェクトリリース後、共通ソフトウェア部分は別のプロジェクト（複数）でも使用することが決まりました。
  • 次のプロジェクトにおいて、共通ソフトウェアにも機能向上が必要と予想されます。
• 最初のプロジェクトで開発したシステムが運用・保守されている期間、共通ソフトウェアは不具合修正、マイナーな機能変更が発生します。

目標

• 共通ソフトウェアが保守地獄とならないよう、プロジェクト毎に別々に構成管理するのではなく、共通ソフトウェアを一元管理できる
• 運用・保守期間は、システムの安定性を最優先とするため、不具合・必要最低限の機能修正のみ適用する
• 次のプロジェクト開発中は、共通ソフトウェアの機能・性能向上、信頼性向上のための修正は積極的に行いたい
• 修正の内容に応じて、どのプロジェクトに反映するかを自由に制御したい
  • 例）不具合はすべてのプロジェクトに反映したいが、新機能は必要なプロジェクトにのみ反映する、性能改善は変更波及範囲が限られているものであれば、多くのプロジェクトに反映したい
  • 例）反映のタイミングは、各プロジェクトのスケジュールに応じてバラバラとなる。運用中のシステムでは、次回の複数の修正をまとめて検証・インストールするときにする（年単位かもしれない）、開発中のシステムならすぐに取り込む、など

検討

リポジトリの管理

複数プロジェクトで共通に使われるので、一元管理するためには、プロジェクトから独立したリポジトリで管理するのが望ましいです。

• 共通ソフトウェア用に独立したリポジトリを構築する

プロジェクトで１つのモノリシックなリポジトリを作成し、共通ソフトウェアをそのディレクトリの一部で管理すると、プロジェクト終了後に共通ソフトウェア部分を抜き出す作業が発生します。ディレクトリが変更されるので、プロジェクトのビルド・テスト・インストールなどの他の作業に影響が及ぶ可能性があります。共通ソフトウェア側からプロジェクト固有のソフトウェアへの隠れた依存が発見され、修正しないと抜き出せないことがあります。

共通ソフトウェアがプロジェクト外での利用を想定しているならば、最初からリポジトリを分けて構成管理するのがよいでしょう。

ブランチの作成

世の中バージョン管理ツールに関する情報が増えていますが、ツールの機能・使い方についての記述が多く、実践的なバージョン管理のノウハウとなると意外に少ないことに気づきました。以下は参考となった資料（日本語）です。
ソフトウェア構成管理の 高度な実践方法 | 東陽テクニカ

パターンによるソフトウェア構成管理 (IT Architects’ Archive―ソフトウェア開発の課題)

パターンによるソフトウェア構成管理から、適用する主要なパターンを挙げると以下となりそうです。

• メインライン
• アクティブデベロップメントライン
• リリースライン
• リリースプレップコードライン

中心となるメインラインを１つ維持し、リリース用ブランチは必ずメインラインからブランチして作成します。リリースのための試験期間の開始時にブランチを作成し、メインラインでの変更から隔離します。リリース後もそのリリースに対する修正はリリースブランチで扱います。リリースブランチの修正は、タイミングを見てメインラインに反映します。

課題

リリースラインからメインラインへの変更反映

ブランチ後しばらくは、リリースライン上の変更をメインラインへマージで反映できそうですが、リリース後時間が経過するほどリリースラインとメインラインとの乖離が大きくなるため、マージが困難になってきます。たとえば、メインラインがリファクタリング等でファイル構成が変わってしまった場合などがありそうです。

メインラインからリリースラインへの変更反映

パターンには書いてないですが、メインラインでの開発中に発見した不具合の修正は、リリースラインにどのようにマージするかが課題となります。メインラインには、さまざまな変更が入っており、リリースラインには望ましくない変更が大半です。その変更のなかから、必要なものだけをメインラインからリリースラインへマージするためには工夫が要りそうです。

あるリリースラインでの変更を別なリリースラインへ反映

上記2つの課題の合成技になりそうです。