構成管理のアンチパターン～TiDD初心者が陥りやすい罠 #tidd

Redmine上でイテレーションを理解してもらうのが結構難しい。
その理由について考えたことをメモ。

【1】Redmineを運用してもらうと、Redmineプロジェクトやチケットの使い方はすぐに慣れてくれる。
プロジェクトの階層化は組織構造をマッピングしてくれればいいし、チケットの階層化もMS ProjectでWBSを作っていた人にとってはとても自然。

だが、Redmineバージョンがイテレーションに相当することを理解してもらうのはとても難しい。
ロードマップがリリース計画になると何度言っても、すぐに理解してくれないし、運用してくれない。
Redmineのバージョンを作らないし、チケットの属性であるバージョンに値をセットしてくれない。
ロードマップを見ながらスコープ管理しろと何度も言っているのに、チケット一覧で数百枚のチケットを平気で一生懸命フィルタリングして、チケットを1個ずつ精査している。

Agile開発のイテレーションの考え方は、WF型開発に慣れた人にとっては理解のギャップが大きいらしい。
その理由は何故か？

【2】Agile開発のイテレーションは、リリース可能なシステムを作る期間という意味であり、イテレーション終了時には必ず本番リリースする。
イテレーションが2～4週間で区切られていれば、定期的なリリースが自然な小規模リリースとなり、Agileな開発スタイルになる。

しかし、イテレーションが理解できないチームを見ていると、開発したソースを本番リリースに持って行くための手順がとても多く、Agileな開発に持っていけないようだ。
その根本原因は、構成管理の使い方が間違っているように思えている。
上手にソース管理されてないので、Excelのリリース管理台帳が必須で、ライブラリアンが手作業で慎重に本番リリースしている。
構成管理がチケット駆動開発のスピードに付いていけてない。

「trunk1本の構成管理」「リリースブランチを使わない構成管理」というアンチパターンを見つけたのでまとめてみた。

構成管理のアンチパターン

View more presentations from akipii Oga

【3】例えば、CVSやVSSを使っているチームでは、trunk1本でソース管理している時が多い。
つまり、本番運用のソースも2次開発のソースも全てtrunk1本でソース管理している。
trunkには本番稼働中のソースも、2次開発でまだ品質が安定しないソースも混じっている。

何故こんなソース管理をしているのかと言うと、ブランチを作るとマージ作業が大変なので、ブランチを作りたくないからだ。
しかも、CVSやVSSはファイル毎にタグ付けできるので、trunk1本のコードラインでも、本番リリース時は、リリースしたいファイルを1個ずつタグ付けすれば間違ってリリースすることもないから問題ない。

だが、タグ付けするために、本番リリースしたいソースの一覧を書き留めたExcelのリリース管理台帳が必要となる。
開発者はソースをコミットするたびに、Excelのリリース管理台帳に修正ソースのリビジョンを書きこんでいく。
そして、リリース時にライブラリアンがExcelのリリース管理台帳を見ながら、タグ付けしてビルドする。

だからライブラリアンの作業負荷はとても高く、ビルド作業やリリース作業は手作業のため、ミスが起きると致命的。
しかもタグ付けやビルド作業自体を自動化しづらい。

すなわち、継続的インテグレーションのプラクティスを実施しづらいし、trunkは常時リリース可能なコードラインではない。
タグ付けしてビルドして、初めて受け入れ可能なモジュールができるので、そこからテストしないと本当の品質が分からない。
だから、いくらタスクをチケット化しても、ソース管理がそのスピードに追いついてないので、アジャイルな開発になりづらい。

「trunk1本の構成管理」というアンチパターンは、構成管理ツールがCVSというリビジョンという概念がない代物だったが故に発生しているように見受けられる。

【4】「リリースブランチを使わない構成管理」とは、2次開発は別ブランチで作業し、trunkは本番運用でソース管理するアンチパターン。
つまり、2次開発が決まった時点で、trunkからブランチを切り、そのブランチ上で開発して、最後にtrunkへマージする。
この手法もCVSやVSSを使っているチームに多い。

この手法は、やはりtrunk1本で新規開発と本番運用の2系統のソース管理を行うのは危険なので、2次開発は別ブランチで自由に開発してもらうという考え方。
確かに、開発者は2次開発ブランチ上で実験しながら開発できるので、開発しやすい。
しかし、この手法の落とし穴は、trunkへマージする最後の作業にある。

2次開発ブランチでいくら常時ビルドして動かしていたとしても、trunkへマージしなければ、本番リリースできるソースにはならない。
しかも、trunkには緊急の本番障害の修正が混じっていたり、他チームの修正が混じっていたりする時があるから、単なる上書きはありえず、2次開発のソースをマージするのはとても慎重な作業が必要。
だから、Excelのリリース管理台帳に2次開発ブランチで修正したソース一覧も残しておき、修正ソースを1個ずつチェックしながらマージする必要がある。

つまり、trunkへのマージがビッグバン結合となり、そこで初めて大きなリスクが発覚する時が多い。
手作業でたくさんのソースをマージする作業ほど嫌なものはない。

「trunk1本の構成管理」「リリースブランチを使わない構成管理」というアンチパターンは、CVSやVSSだけでなく、SVNでも同様に発生しているチームがいる。
多分、構成管理パターンを知っていないのだろうと思う。

【5】「trunk1本の構成管理」「リリースブランチを使わない構成管理」というアンチパターンに対する解決方法は、メインラインモデルという構成管理が既に知られている。
SVNの使い方を調べていた時に随分たくさん書いた。

Subversionのブランチを有効活用してアジャイルに開発せよ: プログラマの思索

Subversionを見直せ: プログラマの思索

Subversionコードラインのライフサイクル: プログラマの思索

TiDDを実践して気づいたことpart2～これがアジャイルだ！と気付いた瞬間: プログラマの思索

メインラインモデルとは、trunkを最新機能を持つ常時リリース可能なコードラインとし、リリースブランチやトピックブランチなど各種のブランチは必ずtrunkから派生させるようにソース管理する手法。
trunkが1本の大きな幹のように、他の枝葉(ブランチ)を派生させるように設定するので、開発者はtrunk1本だけ追いかければいい。
ブランチはtrunkよりも使われる寿命は短いように設定されているのがコツ。

Redmineはもちろんオープンソースのツールはメインラインモデルで開発されている事例が多いので、この手法は少なくとも今までの構成管理の中でもっともましな方法なのだろうと思う。

メインラインモデルでは、trunkもブランチも常時リリース可能なコードラインだから、いつでも即リリースして製品にできる。
VerUpするたびに過去のリリースブランチは廃止して、新規のリリースブランチを派生させて、本番障害の修正はリリースブランチ上で専念すればいい。
アジャイル開発が難しい理由の一つは並行開発でもあること。
2本のコードラインを常時保守する並行開発がメインラインモデルの本質なのだが、品質維持と機能追加という矛盾した開発をうまく分けているのがコツ。

Redmineでは、1プロジェクト＝1リポジトリなので、故意にブランチ単位にRedmineプロジェクトを割り当てて、タスク管理を行うことも可能。
以前の僕は、本番運用のソースで修正が入った場合、新規開発プロジェクトへマージ作業のチケットを作って、発生源である本番障害のチケットのリンクを貼って、手作業でマージするように運用していた。
今なら、MercurialやGitのような分散バージョン管理を使えば、pushやrebaseで簡単にtrunkへマージできるから、ブランチ管理しやすくなってきていると思う。

【6】ソース管理が常時リリース可能なコードラインになっていないアンチパターンによって、タスクをチケット化しても、すぐに本番リリースできる環境にはなっていない。
だから、わざわざRedmineバージョンをリリースタグと紐づける運用をする本当の意味が分かってない。
本番リリースの怖さはソフトウェア技術者なら皆知っているはずなのに、本番リリースの作業を自動化したり、本番リリースに向けたタスク管理やソース管理を行う環境を整えていないのが不思議だ。

Redmineの良さは単なるチケット管理だけでなく、構成管理ツールと連携して、要件からビルドモジュールまでのトレーサビリティや製品ライン系列の開発も実現できる仕組みがあること。

小刻みにリリースしていく小規模リリースをRedmine上で実現できなければ、Agile開発の醍醐味である計画ゲームと言うスコープ管理や、定期的なリリースから発生する開発のリズムを感じ取ってくれない。
この辺りのアンチパターンは他にも探してみたい。