BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース TFSはどのようにして3週間のリリースサイクルを受け入れたか

TFSはどのようにして3週間のリリースサイクルを受け入れたか

ブックマーク

原文(投稿日:2012/10/31)へのリンク

 

Buck Hodges氏が、Team Foundation Serverチームにとって長いリリースサイクルを持つのは良くないと主張している。氏の考えでは短いリリースサイクルは単にスプリントの成果を出荷すること以上の意義がある。ソフトウエアをどのように企画し開発するのかについての変更も同時に行う必要があるからだ。

元々、Team Foundation Serverは数年のサイクルでリリースされていた。MicrosoftのBuck Hodges氏によればこのサイクルはTeam Foundation Serverの開発者の振る舞いを劣化させていた。厳しいマイルストンに直面した場合、開発者たちは不完全な機能でも無理矢理製品に盛り込もうとしてしまった。新しい機能の提供を2、3年も送らせるより、リリース後の安定期間内でバグ修正をした方がいいと考えてしまうのだ。その結果、TFSはリリースサイクル内で2000を超えるバグを抱えることになってしまった。

また、インターネット時間の概念も問題のひとつだ。オンラインサービスのユーザは頻繁な更新と改善を期待しており、バグ修正を待たなければならないことに不満を持ちやすい。したがって、オンラインバージョンのTFSへの移行を計画する顧客に対して、アップデートが数年間隔になることを理解させるのは難しい(オンラインバージョンはリリースされたばかりで名前はTeam Foundation Service)。

計画

リリースサイクルが短くても、必ずしも方向性が欠如しているということではない。TFSの開発者は今から18ヶ月で実現したいことを表す高いレベルのストリーボードから作業を始める。これを6ヶ月毎の計画に落とし込み、アプリケーションの特定の部分に注力できるようにする。

TFSチームには130人のメンバーがいる。メンバーはバージョンコントロールやアイテムトラッキング、自動ビルドなど主要な機能毎にチームに別れている。各チームは12人(開発者6人、テスター5人、1人、2人のプロジェクトマネージャ)でチーム毎に機能のバックログを管理する。

マーケティングと開発を分離するため、機能を有効にしないでTeam Foundation Serviceへ盛り込むこともある。こうすることでさらにテストをして、大きな製品発表の時にまとめて発表することができる。

スクラム

TFS 2012ではスクラムを開発手法として採用しており、サイクルは3週間だった。チームが感じたのは、短いリリースサイクルの場合は短さに比例して管理コストが大きくなる一方、長いサイクルの場合は正しい方向に進むようにするのが大変で以前のバージョンの問題に直面する場合もある。

スクラムを選んだ理由は顧客が採用しているのと同じ手法でソフトウエアをテストするためだ。Microsoftによれば、スクラムは顧客の中で最も人気のある手法だ。

チーム間のコミュニケーションはスプリントの開始時と終了時にやり取りされるメールで行われる。スプリントの開始の時は開発対象のストーリーのアウトラインが書かれ、完了時には完成した機能のデモが含まれる。

リリースのリズム

TFSが3週間のスプリントを行ったとしても、実際のリリース4ヶ月毎になる。したがって、各リリースは大規模になり問題を含みやすい。各リリースのサイズを小さくするため、1ヶ月毎のリリースにしようとしたが、スプリントのサイクルと近くなっため、結局両者は同じサイクルになった。

この方法を採用した結果、従来バグ修正期間と位置づけていた安定期間の概念を捨てる必要があった。代わりに3週間のスプリントの後に1週間の検証期間を設けた。この期間はバグ修正のための期間ではない。上手く動かない機能を無効にしたり取り除いたりする期間だ。この検証期間は次のスプリントの開始と重複する。

テスト

あるひとつの機能を実装するのに3週間のスプリントを使う必要がある場合、そのスプリントのリリースされず、次のスプリントでテストを行い、問題なければリリースを行う。1週間か2週間しかかからない機能は単一のスプリント内でテストしリリースできる。

テストはすべて自動化されており、回転方式で実施される。現在はテストの実行に2、3時間かかる。テストサイクルが長いので、テストをパスするためにすべての変更をチェックインをする必要はない。必要なのはビルドできる最小限のチェックインだけだ。下記は開発者が受け取るチェックインメールの例だ。

ブランチ

サービス(オンラインバージョン)とボックス(インストールバージョン)は同じコードベースを使っている。ほとんどの機能はメインのブランチに実装されている。明確に分離しなければならない機能だけが別々のブランチに実装されている。機能ブランチはスプリントの開始時とその機能が完成したときにメインのブランチにマージされる。

スプリント完了時に変更はメインのブランチからプロダクション用のブランチと四半期毎に更新されるブランチに移行される。

このプレゼンはChannel 9で見ることができる。

 

この記事に星をつける

おすすめ度
スタイル

BT