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

パターンによるソフトウェア構成管理を大学の図書館で見つけて読んでみたところ意外に良書だったので紹介する。

16個のパターンを紹介している。

Pattern Name	Summary
Mainline	マージを最小化する。メインラインで開発することによってアクティブなコードラインの数を管理可能な集合にする。
Active Development Line	Active Development Lineを作ることによって急激に成長するコードラインを安定化する
Private Workspace	Private Workspaceによって、統合の問題で集中できない状況から守る、また自分の変更が他の人に影響を及ぼさないようにする
Repository	必要なものを全て持っているRepositoryを設定する
Private System Build	Repositoryにコミットする前にPrivate System Buildによって自分の変更がビルドを壊していないか確認する
Integration Build	Integration Buildを定期的に行うことによって自分のコードベースが信頼できるビルドができるか確認する
Third Party Codeline	Third Party Codelineによってベンダーコードを管理する
Task Level Commit	タスク毎にソースコードの変更を整理する
Codeline Policy	開発者がいつコードラインにコードをチェックインするか、各コードラインへチェックインする前に行う手続きについて理解することを助けるCodeline Policyを作る
Smoke Test	Smoke Testをすることによって自分の変更がシステムを壊していないことを保証する。
Unit Test	Unit Testを実行することによって自分の変更のあともモジュールが動作することを確認する
Regression Test	Regression Testを実行することによって既存のコードが変更に影響を受けていないことを確認する
Private Versioning	Private Versioningを使えばローカルに複雑な変更を実験的に行うことが可能になる。それはバージョン管理システムの他の利点を甘受しつつできる
Release Line	Release Lineを確立することで、現在の開発に影響することなくリリースバージョンを保守する
Release-Prep Codeline	Release-Prep codeline上で安定化作業を行うことで、新しい作業はアクティブなコードライン上で続けながら、リリースに向けての安定化ができる
Task Branch	Task Branchでチームの他のメンバーの仕事に影響を与えることなく破壊的なタスクを実行できる

上記のまとめと、下記の図は http://www.scmpatterns.com/book/pattern-summary.html より引用。

パターンは先人たちのベストプラクティスを表したものなので、智慧がぎゅっと圧縮されている。自分たちの開発のスタイルがどこにいてどんな問題を持っているかの地図になる。迷子になる前に、あるいは迷子になった時、自分の位置を確認するのに使える。

自分のチームが使っているツールによってどのような作業が支援されているのか、どのような作業が難しいのかなどを確認してみよう。

本書は分散型バージョン管理システムが一般化する前に書かれたので分散型のパターンがないようにみえるが、本書の価値は変わらない。手元に置いておきたい一冊である。