プログラマの思索

Perforceというソース管理ツールがある。
このツールは、CVSやSVNよりもマージやブランチ作成などの機能が優れていて、特にゲーム業界でよく使われていると聞く。

PerforceのHPにSW構成管理の良い記事があったのでメモ。
＃あくまでも書きかけのメモ。

メインラインモデルとSW構成管理の新たな関係。
継続的な改善と変更管理の密接な関係。
インクリメンタルな開発スタイルは品質管理、リリース管理に密接に関係する。

【元ネタ1】
PERFORCE ソフトウェア構成管理の高度な実践方法（ベストプラクティス）

【1-1】メインライン（主流となる開発経路）を持つようにする。

何故、trunkというメインラインを1本ずっと保持し続けるか、の良い理由が書かれている。
メインラインを昇格していくモデルでは、開発者へ別の開発環境を作るという不要なコストを強いるから。
ソフトウェア開発の殆どの無駄な作業は、開発環境や本番環境の設定作業など、非常に神経質にならざるを得ない作業が多い。

【1-2】ブランチしようとするときに物理的なコピーをしない。

Subversionには、コピーという機能がある。
この機能は、ソースのコピーだけでなく、ソースの編集履歴も引き継ぐという重要な機能も持つ。
このおかげで、ソースの中に何故こんなパッチが追加されたのか、という変更理由をいつでも探すことができる。

だから、ブランチを作る時も、必ずSVNのブランチ作成機能を用いて、変更履歴も引き継ぐようにする。
つまり、最近のSW構成管理では、ITILの言う変更管理が非常に重要なのだ。

【1-3】「ソース＋ツール＝製品」。

SW開発では、プログラミングよりもビルド作業やリリース作業に非常に神経を払う。
XPのプラクティスの一つである継続的インテグレーションは、常時ビルドしてリリース可能なシステムを保つ点を指摘し、開発者へSW構成管理の重要性を認識させた。

つまり、製品は、ソースとそのソースファイルを入力とするビルドツールがセットになって初めて作られる。
この部分は、ITILの言うリリース管理に相当するだろう。

【元ネタ2】
PERFORCE 変更管理を通じた製品品質の向上

【2-1】実際、それはちょうど"編集－コンパイル－実行"のサイクルに良く似ている。
そのため、すべてのプログラマは、既にこのプロセスについて知っているはずである。

アジャイル開発が何故プログラマに熱狂的に支持されるのか？
おそらくその理由は、軽量言語のプログラミングスタイルと同じだからだ。

【2-2】このテクニックのもう一つの特筆すべき点としては、重要な出荷に関する問題を早い段階で解決することである。
しばしば、非常に重要な項目が、最後まで忘れられている場合がある。
各段階で完全な製品を出荷することによって、我々は、それらをより早く発見し、最終段階でのパニックを避けることができる。
納期間際での作業は、欠陥が紛れ込み易く、もしそれが何かクリティカルなものであれば、そのとき製品の品質はより悪化してしまう。

何故、頻繁なリリースが必要なのか、という説明。
リリース作業、ビルド作業は重要な作業であるとは知っているものの、手間がかかるから、普通は開発者は嫌がる。

インクリメンタルな開発プロセスのおかげで、メインライン(trunk)は常にリリース可能な品質に保たれる。

【2-3】この段階であなたは、バージョンプランニング－, ソフトウェアプロジェクトプランニング"の手法－を用いて、製品の次のバージョンに対する計画を立てるこ とが可能となる。
一つのバージョンは、製品の仕様が進展していく過程での一区切りである。バージョンはあなたが実際に予定したスケジュールの中で満たそうとした一定の要求サブセットである。バージョンを絶え間なく変わる要求のスナップショットとして考えても良い。

バージョンという概念がSW構成管理では非常に重要だ。
バージョンとは、Subversionのtagそのもの。
バージョンが作られるタイミングは、本番環境へリリースする時と一致する。

つまり、SVNリポジトリにある特定のリビジョンのスナップショット。
更に、SVNリポジトリにソースだけでなく、ExcelやWordの仕様書も含まれていれば、同様にリリース時にtagが付けられる。
その意味では、バージョンとは、成果物と仕様を定めたベースライン。

【2-4】このような詳細度レベルで計画を立てることに価値があるのは、せいぜい2ないし3バージョン先までであろう。というのも、要求は変更されるものであるし、次のバージョンで再度それに取り組む事になるからである。それよりも先の計画はラフなものにすべきであり、詳細な計画を遠い将来に亘って作成しても、労多くして益少なしである。
重要な要求に対してそれぞれバージョンを指定しなさい。

タスクブランチを作るタイミングは、trunkやリリースブランチでは対応しきれない大きな仕様変更が来た場合。
タスクブランチは、直近のターゲットバージョンから1つか2つ先のバージョンを指定するだろう。

【2-5】この変更管理プロセスのキーとなるコンセプトは、継続的な改善である。 これは常に要求に対して近づいていく事を意味し、また変更によって要求から遠ざかる事がないように する。
図4は、 私がこのシンプルな考えを説明するために好んで用いるダイアグラムである。 これは"ソフトウェア構成管理"とはどういうものかについて表している.

インクリメンタルな開発プロセスと変更管理は表裏の密接な関係を持つ。
XPなら2週間、Scrumなら4週間の短いサイクルで小規模リリースできるには、簡単で強力な変更管理の機構が必要だ。
強力な変更管理機能があって初めて、多数のバグ修正や仕様変更を短いイテレーションに混ぜ込んでもデグレが起きない開発スタイルができあがる。

【2-6】変更を追跡し管理する目的で、2種類の文書が使われる: 「問題」と「変更」である。
「問題」とは、製品が顧客の要望を満たしていない点について報告された文書である。これは、製品がその仕様に従っていない（欠陥）か、仕様が顧客の要望を表していない（エンハンスメントまたは新規要求）のいずれかである。この違いは顧客にとっては大したことではない。要するにどちらの場合でも、彼らが望む事を製品が提供していないので、変更して欲しいと言っているのである。本文書で述べられているプロセスは"新規開発"と "バグ修正"を同様に扱っている。「問題」は、製品にプロブレムが見つかったときにはいつでも作成される。「問題」はバグ報告書と改善要求を包括する。
「問題」は、変更に対する唯一のきっかけである。変更が顧客に対してその製品を改善 しないのならば、それを行う価値を持たない。インフラの改善であっても、結局は価値を上げる必要がある。

ITILでは、問題管理と変更管理を使い分ける。
エラーが、既知の問題なのか、そうでないかによって、問題コントロールとエラーコントロールの2種類を使い分ける。

【2-7】変更のチェックは、製品の完全性を保つために極めて重要である。それゆえ構成管理に とって重要なステップであるチェックとは、全体の設計戦略に対する変更の適合性をシニ アエンジニアがいかに保証するかという事である。そこは、CMMレベル3のキー・プラクティス[KPA1.1, L3-93]の一つである"ピア・レビュー"7のような確認のステップを組み入れるべき格好の場所である。(確認はCMMレベル3 [CMMI1.02, p267]のキー・プロセス・エリアである。) さらにはその変更が、そのグループに対するベスト・プラクティスとして適している かどうか、ソフトウェア品質保証がチェックできる段階でもある。

レビューを使うタイミングは、変更管理プロセスで使うべき。
レビューは欠陥のあら探しが目的ではない。
レビューは、よほど上手に運用しなければ、すぐに官僚化して、重厚なプロセスになってしまう。

【2-7】我々は、顧客が既に持っているリリースに対してパッチを当てることで、素早く顧客の問題を解決することができる。これは問題を修正するために、出来るだけ小規模で迅速な変更を行う事を意味する。これは、最新のマスター・ソースコードからビルドしたものを顧客に出荷するよりは良い。というのは、それでは、顧客に問題を引き起こしてしまうような方法で変更されている可能性があるためである。また最新のマスター・ソースコードを出荷する事も危険である。それらは、顧客の環境と互換性のない変更を含んでいる可能性があるからである。また、その仕様が分からないので（従って、どういう事をしようとしているものなのかを顧客に話す事が出来ない）、将来保守するのが容易ではない。それらは、おそらく最後のバージョン以降、十分なテストが行われていない。安定したリリースにパッチを当てることは、迅速で高品質な修正結果をもたらす。これが、バージョンブランチを推奨する主たる所以である

本番環境で動くリリースブランチとメインライン(trunk)を何故、別管理にするのか、という理由。
ITILの問題管理の観点からの説明。
品質が安定した本番リリースブランチ上ならば、迅速なバグ修正が可能で、更に品質も保たれる。

【2-8】欠陥に対する修正変更は、バージョン・ブランチにおいてのみ行われる。欠陥とは、リリース製品がバージョン仕様を満たしていない箇所を指す。通常"バグ"と呼ばれているものは、この定義に含まれる。9ほとんどの場合、製品がその機能の一つを実行出来なくなるものである。ある意味でバージョン・ブランチは、マスター・ソースコードがあるべき要求に向かって進化していくのと同様に、その仕様に向かって進化する。
最も重要な事は、バージョン・ソースは既知の物だという事である。そこからビルドされる製品は、完全にテストされた後でリリースされており、小さい変更は結果が予測可能なものでなくてはならない。こうした理由から、重要なことは余り多くの変更を行わない事であり、修正を行う場合は、顧客が抱えている特定の問題を解決するための必要最小限のものとすべきである。この狙いは、問題を迅速に修正することであり、他の問題を持ち込まないようにすることである。

本番環境で動くリリースブランチとメインライン(trunk)を何故、別管理にするのか、というもう一つの理由。
ITILの変更管理の観点からの説明。

本番リリースブランチでは、変更の影響が少ないパッチだけ当てる。
そうしなければ、品質を保持し続けることができない。

【2-9】受け入れ検査は、バージョン仕様に基いて行われる。バージョン仕様は、製品がどういうものでなければならないか（あるいは、要求とどのように違っているか）ということと、リリースがそれにどのように適合していなければならないかということについて厳密に述べたものである。受け入れ検査開発は、バージョンが計画されるのと同時に、製品の開発と平行して始めることができる。

バージョンとは、単にソースのスナップショットだけでなく、仕様のスナップショットでもある。
例えば、アプリケーションには必ずChange.txtが付属しているが、これは、機能の変更履歴そのもの。
同様に、業務システムであっても、バージョン履歴という変更履歴が、受入テストの仕様にもなる。

わずか２～４週間のイテレーションで次々にリリースしていく開発スタイルは、技術力に裏打ちされた開発プロセスが無ければ非常に難しい。
SW構成管理のインフラが整っていなければ、いくらアジャイル開発したくても、運用できないのが現実だと思う。