無料ブログはココログ

« MobiRubyはオープンソース! - 秋の京都で MobiRuby をつつく会 in はてな その2 - | トップページ | さかば流・論文作法 その1 - 論文の構成 - »

[#TiDD] パッチはコア資産 - DVCSの考察 -

“No Ticket, No Commit!” の誤解

チケット駆動開発の基本ルールである“No Ticket, No Commit!”の誤解の一つは、コミットに1対1のチケットが必要であると言う考え方です。この反例として、「Redmineによるタスクマネージメント実践技法」の事例があります。

この事例では、Redmineのワークフロー機能を利用して、リリース後のコードと開発中のコードの更新抜けをなくすというものです。

具体的には、チケットをクローズする権限を特定の担当者に与えておき、修正が全ての関連プロダクトでコミットされていることを確認することで、修正の漏れをなくしています。

この例では、一つのチケットに2つのコミットがありますが、効果的なチケットの使い方になります。

DVCS(分散バージョン管理システム)

この事例では、DVCSを用いると作業が容易になります。バグ修正を行うトピックブランチを作成して、その修正(パッチ)を2つのブランチに反映すれば良いのです。

このやり方を考えてみると、パッチがコア資産であることがわかります。コア資産とは、複数系列のソフトウェア製品を開発するソフトウェアプロダクトラインの用語で、ある製品を開発する際に再利用されるものです。仕様書、ソースコード、試験項目、開発標準など、再利用しやすい形で整備されます。

バグ修正の事例で、ある製品を開発するのに使われた共通な資産は、本体のソースコードではなく、修正差分であるパッチです。このようなパッチの蓄積がソフトウェア開発を進めていきます。

昔のオープンソース開発

かつてnewsシステムという、バケツリレー式に情報を伝播する世界規模の掲示板のようなものがありました。誰かが記事やコメントなどの情報を書くと、それがサーバー間で転送されて共有されます。今のインターネットの祖先の仕組みで、自分のサイト内で世界中の情報を得ることができました。

当時は、これがオープンソース開発に利用されていました。さまざまな技術的な議論のほか、ソースコードのリリースや、バージョンアップ時の修正差分も世界中に配信されていました(ちなみに、私はnewsでrubyを知りました)。

ブランチ

オープンソースの配信は色々なものがありました。

1) 全ソースコード
2) 日本語対応パッチ
3) 新バージョンとの差分パッチ
4) バグ修正パッチ

ここでいうパッチとは修正の差分ファイルで、元のソースとパッチからpatchコマンドで修正後のファイルを作成する事ができました。

これらは、「サルでもわかるGit入門」で紹介されている「A successful Git branching model」のブランチに当てはめると、それぞれ

1) メインブランチ
2) フィーチャーブランチ(トピックブランチ)
3) リリースブランチ
4) ホットフィックスブランチ

に相当します。オープンソースは単純でシーケンシャルな開発ではなく、多くの修正がそれぞれのサイトで分散して行われ、その結果が共有されていました。

パッチを使う際は、その順序が問題になりました。たとえば、あるバージョンに日本語パッチをあてるとバグフィックスのパッチは適用できてもバージョンアップのパッチが適用できなくなって、まず、バグフィックスして、バージョンアップして、日本語パッチを適用するなどという順序で解決されることや、パッチのマージが行われたりしました。

これらの様子は、DVCSのブランチ処理によく似ています。オープンソースの開発から生まれたので、当然と言えば当然ですが、、。

身近な複数系列の開発

かつて複数系列の開発は、プロダクトライン呼ばれるような大規模な開発が中心でした。

しかし、考えてみると英語版、日本語版、特殊機能追加版など、オープンソースの開発も複数系列の開発になります。また、最初に挙げた事例の様にリリース後にも開発を継続していれば、自然と複数系列の開発になります。

開発対象が複数系列になると、追加機能開発は特定の系列に修正した後に他の系列に同じ修正をするよりは、オープンソースのように機能追加の修正パッチを作成して各系列に適用する方が作業が簡単になります。

従来のバージョン管理システムは中央集権的にメインライン(trunc)を中心に管理する必要があり、複数系列の同時開発になると、その管理が面倒でした。DVCSは分散開発が前提なので、複数管理が容易になっています。

パッチ単位の開発へ

SVNや前の世代のCVSでは、CIを実現する目的でバージョン管理のリポジトリにはビルド可能なコードだけをコミットする、ということが常識化していました。そこで、開発中のコードをとりあえずコミットすることが許されなくなりました。

しかし、DVCSならブランチを容易に作ってマージできますので、CIや他の人に迷惑をかけることを気にせずにコミットできます。

実はCVSのさらに前の世代のRCSは、ファイル単位のバージョン管理でした。当時はビルド(というかmake)するための共通ディレクトリを作っておいて、作業が完了する毎に共通ディレクトリのファイルを更新するという使い方をしていました。

DVCSを見ていると、RCSでの開発や昔のオープンソース開発を思い出させます。単純な構成管理を中心に考えると、VCSによる統制の取れたメインラインの管理が向いていました。しかし、複数の系列やスピーディな開発が求められることによって、個人を中心とした開発が復活しようとしているのかもしれません。

ソフトウェアはどう作るべきか、一気に作る時代は終わりを迎えようとしています。ブランチ毎のパッチ単位に開発する事を繰り返す事が、ソフトウェ開発の基本になる時が近づいていると思います。

« MobiRubyはオープンソース! - 秋の京都で MobiRuby をつつく会 in はてな その2 - | トップページ | さかば流・論文作法 その1 - 論文の構成 - »

チケット駆動開発」カテゴリの記事

コメント

コメントを書く

コメントは記事投稿者が公開するまで表示されません。

(ウェブ上には掲載しません)

« MobiRubyはオープンソース! - 秋の京都で MobiRuby をつつく会 in はてな その2 - | トップページ | さかば流・論文作法 その1 - 論文の構成 - »