パターンによるソフトウェア構成管理

パターンによるソフトウェア構成管理

• 訳本2006/10発売

–情報はちょっと古い

–すでにSVNなどで実装されているものもある

–パターンというかポリシーっぽいものもある

• 全体で250ページくらい

–概念説明が50ページくらい

–パターンの解説は130ページくらい

–付録でCSV時代のツール説明が50ページくらい

基礎

/main

/release1.1

main.1 main.2

タグ→

コードライン↓ ←ブランチ化 ←マージ

↑

コードラインのバージョン

Bug01修正

今日あんまり説明しないパターン

パターンだけど常識

• Unit Test単体テストしてね

• Private System Buildローカルでビルドしてね

• Integration Build全体結合してね

• Smoke Test 疎通くらいしてね

• Regression Test回帰テストしてね

パターンってかポリシー

• Private Workspace個人作業場所確保

• Private Versions個人単位で無限Undo

• Repository構成品目の一元管理

• Task Level Commitこまめにコミット

Mainline

Mainline

• コードライン（ブランチ）の乱立を防ぐため、幹のラインを定めること。

• Release lineなどはできるだけMainlineから切るようにする。

Task Branch

Task Branch

• 長期にわたる変更・重大な変更等をブランチを切って作業すること。

• ただし、MainlineとTaskBranchは時々修正をマージし合うほうがいい。（最終マージのコストを低くするため）

Active <------> Stable

• Active

–細かいコミットが多い

– コミットのハードルが低い

–マージが簡単

–品質が不安定

• Stable

– コミットのハードルが高い（チェックリスト・承認委員会etc）

– コミット回数が少ない

–品質が安定

–マージが大変

• どちらがよいとは言い切れない。

• バランスを取るのが大事。

画像探すの疲れました＼（＾ρ＾）／

Codeline Policy

• 各CodelineにStableとActiveのバランスを設定すること。

• 例：Release Lineであれば安定性重視でコミットにCCBへの申請など事務処理をつける

• 例：Mainlineであれば活発さ重視でSmokeTestまでしかしない

Active Development Line

• コードラインの安定と活発さのバランスを取るようにCode Line Policyを定めること。

Release Prep Codeline

• リリース前にコードラインを安定化させたい。

• Mainlineからブランチを切って、コードラインを分けておくこと。

• あまりに早くやり過ぎるとMainlineにも影響が

ある修正作業のマージが大変になるので、時期を見極めること。

Release Line

• リリースした時点でブランチを切って、コードラインを分けておくこと。保守用に使う。

• Release Lineに加えた修正でMainlineにも影響があるものはマージする。

Third Party Codeline

• 第三者から受領した構成品目は、プロジェクトのタイミングと異なる都合でリリースされる

• 専用のコードラインを作ってレポジトリに入れておくこと。

ブランチングに関連すること

• Mainline

• Task Branch

• Release Prep Line

• Release Line

• Third Party Codeline

テストに関連すること

• Unit Test

• Private System Build

• Integration Build

• Smoke Test

• Regression Test

グッドプラクティス

• Private Workspace

• Private Versions

• Repository

• Task Level Commit

バランスに関連すること

• Codeline Policy

• Active Development Line

まとめ：重要な概念Codeline[Active <----> Stable]

photo

http://www.public-domain-photos.com