「パターンによるソフトウェア構成管理」スティーブ・P・バーチャック、ブラッド・アップルトン著

ソフトウェアの開発が、「開発→リリース→メンテナンス→開発→リリース→メンテナンス」の一次元的なループであれば問題ないけど、実際は開発の途中で古いバージョンのメンテナンスが入り、特殊なバージョンの作成が入り、企画変更が入り、同時進行の開発がスタートする。当然それらは複数人による作業となり、ある担当者が加えた変更を別の担当者が知らない場合もある。そうなると規模が大きくなった時、あるバージョンでどのコードが実際に使われたのか、実際に動作が確認されている最新のコードはどれかすらおぼつかなくなる。
そういったソフトウェア開発を管理するために有用な16のパターンに分類し紹介している。のだけど、どうも俺にはぴんと来なかった。パターンの中にも具体的なやり方もあれば心構え的なものがあったり、あまり切り口が統一されていない感じがした。
と読んだ時には思ったんだけど、これを書いていて気付いた。これはパターン自体を紹介した本ではなく、そのパターンを使う時の心構え、気を付けるべき事について書いた本だったのだ。だからたとえば「Smoke Test」の章では「Smoke Test」自体が何なのかの説明はない。「Smoke Test」が何かは読者がすでに知っているという前提で、それをどう利用するかについて書いている。それが分かったらだいぶすっきりしてきた。

パターン1 Mainline
あるソフトを元にして、新しい開発が複数同時に行われる時に、互いの影響を受けないようにそれぞれ独自に開発する場合がある。ただし、最終的にはそれらは統合する必要があり、無節操に分岐した開発成果のマージ作業のリスクは大きい。なので、常に正しく動作する「mainline(本流)」を定め、本流に対してマージするようにする。開発が終わったら本流に統合し、不用意にブランチが増えないようにする。

パターン2 Active Development Line
後に登場するReleaselineとの対比で、Releaselineが十分なテストを行ったソフト、Active Development Lineはそこそこテストしてあるソフトという感じか。いちいちReleaselineに統合して十分なテストをしていると開発スピードが落ちてしまう。そこで開発途中では、不整合が起こる可能性はあるけどある程度テストしてあるActive Development Lineを使用する。

パターン3 Private Workspace
実際に作業する場合はMainlineのようなところからコードを持ってくるところから始まる。そうすると、自分が作業をしている間に、別の作業者によってMainlineに変更が加えられているかもしれない。そんな風に自分が変更を加えているコードや環境が古いものに変わっている事を考慮するための心構えやルール。

パターン4 Repository
MainlineだとかActive Development Lineだとか関係者全員がアクセスできるサーバようなところに保管されており、各担当者はそこからコードなり実行ファイルなりを取得してくる。その集めておくところをRepositoryと呼ぶ。担当者が作業するために必要なファイルはすべて1つのRepositoryの中に入れておくことが大事。

パターン5 Private System Build
Private Workspaceにより、自分の開発環境を独立させておくと自分の環境下で自分の担当部分の開発はスムーズに進むだろうけど、いざ統合しようとした時に不整合が生じるかもしれない。だから、実際に統合する前に、自分の環境下で全体との統合を行えるようにする、と言う事か。言ってる事は分かるけど、この本の中で紹介されているような、自分のコンパイラと製品ピルドで使うコンパイラの互換性がない場合というのは想像ができない。けど、ものによってはそういう事はあるんだろうな。いろんな製品で使われるようなライブラリのようなものを担当してるとそういう事になるんだろうか。

パターン6 Integration Build
たぶんPrivate System Buildの後、自分の環境でビルドした後に、自分の変更を公にして他のコードと統合する事をIntegration Buildと呼ぶのだろう。いくらPrivate System Buildで問題がなくても、その時自分が使っていたコードはすでに古いものかもしれない。Private System Buildで問題がなくIntegration Buildで問題が発生するとなると、それは自分の担当部分だけでは完結しない問題だ。他の開発者の変更との面倒な調整作業が必要になってしまう。そういう余計な手間をなるべく少なくするための注意事項。

パターン7 Third Party Codeline
サードパーティ製のコンポーネントを管理する方法。サードパーティ製だとリリースのタイミングが自分達と違ってくる。また、サードパーティ製コンポーネントに自分達で手を加えている場合には、新しいバージョンに再び同じ変更を入れなければいけないかもしれない。だから自分達の製品とは別にサードパーティ用のコードラインを作成して管理しようという話。だと思う。

パターン8 Task Level Commit
一度に多くの変更を加えてしまうと、問題が発生した時にどの変更が原因なのかを突き止める事が困難になる。また、その原因となった変更のみを元に戻す事も難しくなってしまう。なので、粒度の細かいタスクを設定し、タスクごとにチェックインを行うようにする。

パターン9 Codline Policy
コードラインは、Active Development LineやらThird Party CodelineやらRelease Lineやら、複数存在することになる。それぞれのコードラインに合った変更手順や変更タイミングをルール化する必要がある。

パターン10 Smoke Test
スモークテストとは、重要な機能や問題が発生しそうな機能に絞って行う簡単なテスト。変更を統合する前にスモークテストを行い、基本的な問題がない事を確認してから、他の部分と統合する。統合してからのテストは規模が大きくなり時間がかかるためスモークテストをあらかじめ行っておく事は有用である。しかし、網羅的ではないため統合テストに代わり得るものではないことに注意する。

パターン11 Unit Test
統合テストは規模が大きいため細粒度のテストは行えず、また問題が発生した時に原因特定に時間がかかる。そのため単体テストが重要。

パターン12 Regression Test
あるバグ修正が原因で別のバグが発生している場合がある。そういう事が起こっていないかどうかを確認するテストが回帰テスト(Regression Test)。回帰テストのテストケースを作成するこつについて。回帰テストは不具合の原因特定までは行わず、不具合が発生するかしないかを確認する。過去に発生した不具合を重点的にテストする。

パターン13 Private Versions
Private Workspaceを使用して自分の環境下で作業していると、その作業は履歴に残らない。かといってあまり頻繁にチェックインするとそれだけ後戻り作業が公になってしまうし、他の開発者にも影響が与えてしまう。バージョン管理システムのRepositoryに、開発者のプライベートな領域を用意する。

パターン14 Release Line
リリースしたタイミングでMainlineにラベルを付ける事でリリースしたソフトのコードを識別する事もできる。しかし、Mainlineでは次の開発が行われている。新規開発部を含めずにリリースしたソフトを変更するために、保守用のコードライン、Release Lineが有用。

パターン15 Release-Prep Code Line
リリース前にはコードを安定させなければならない。しかし、同時開発中の変更が次々に追加される。そのため、新しい変更を加えず安定させるための修正のみを入れるラインをリリース前に用意する事が有用。

パターン16 Task Branch
長期のタスクで他への影響も大きい開発はMainlineとは分岐したブランチを割り当てる。タスクが完了してからMainlineにマージする。