Share via

マイルストーン品質と "ドッグフーディング" (Matt Gertz)

  • Article

ハードで実り多い仕事の結果、次期バージョンの Visual Studio、Team System、および .NET の開発に備える目標を掲げたマイルストーン品質 (MQ) を達成しました。Visual Basic に限った話題ではありませんが、この場を借りて、他の Visual Studio および .NET 製品同様に Visual Basic にも大いに影響がある、今回の成果を皆さんにご紹介したいと思います。

以前のブログにも書いたように、新しい機能や、その機能の内容がツールやプロセスを次のサイクルに進めるうえで合ったものになっているかどうかなどは、MQ の作業には含まれません。エンジニアリング プロセスを途中で変更すると、多大な混乱が生じるため、コーディングを開始する前にこの仕事を完了していることが重要です。今回の MQ は我々にとって困難なもので、エンジニアリング上の大きな変更が伴いましたが、それだけに順調に達成できた喜びがあります。

以前の投稿で書いたとおり、MQ では "ドッグフーディング" (開発の完了まで未完成のコードを自分たちで使うこと) に時間の多くを割くことを決定しました。その他のセットアップ作業も MQ で行ったのですが、この投稿ではドッグフーディングへの取り組みを中心に書くことにします。ドッグフーディングを実施する理由は次の 3 つです。

1.       利用環境の安定性の向上 :  皆さんが実際に使用される前に、毎日使用する中でバグを見つけることができます。

2.       販売する製品を自分も使う :  皆さんにお勧めするなら、自分たちも使う必要があります。

3.       最良の開発ツールだから使う: 趣味の領域から大企業のソリューション開発まで、すべての開発用途に適する最良の製品開発基盤を提供している自負が私たちにはあります。Visual Studio を開発するための最良のツールは Visual Studio なのです。

今でこそドッグフーディングに慣れたものの、かつてはこれほど早期の段階で実施してきませんでした。通常、最初のベータ版と次のベータ版の間、コードがほぼ完成した後で転換していました。以前のバージョン (全面的に書き換えた Visual Studio .NET 2002 など) では、その段階に至るまでコードを実際に統合できなかったため、この方法に意味がありました。この方法のマイナス面は、ドッグフーディングの開始が遅れれば、カバー範囲を同じにはできないことです。ベータ版では、新しい機能を開発するのではなく、バグの修正のみに特化して注力し、品質の高い機能を開発することが VS、TS、および .NET の本質となるからです。しかし、安定性の高いコード基盤上に構築する今回の開発は、これを活かして早期にドッグフーディングを行い、開発バグを初期に発見する (または混在するのを防止する) ことができ、機能が固まる前に調整を加えることができます。これが実現するのは、Windows チームや Office チームが早期にドッグフーディングを実施するのを常々うらやんでいた私にとってわくわくする出来事でした。

今回のドッグフーディングの準備作業は、Team Foundation Server と SxS (Side-by-Side) サポートの 2 種類の領域に対して実施しました。

Team Foundation Server (TFS)

以前の製品サイクルでは、バグの追跡に専用システムを使用し、コードの保存には別のシステムを使用し、機能の進捗状況の追跡にはバグ レポートとスプレッドシートをいくつか組み合わせて使用していました。これらの間には何の関連付けもなく、どの報告ステータスも必要以上に複雑でした。我々の規模のコードベースでは、丁寧なライフタイム管理処理が求められるため、こうした 3 つ (その他多数) の要素をすべて扱う自社製品、Team Foundation Server (TFS) への切り替えが長い間の目標でした。

この変更を声高に主張した本人だったにもかかわらず、TFS への切り替えにかなり神経質になっていたことを、ここで正直に告白します。Visual Studio、Team System、および .NET を一緒にすると、実に大きな組織になります。全社でなく、この組織 (Developer Division) だけを取っても、世界で 5 本の指に入る規模のソフトウェア ベンダーになります。我々は長い間独自の方法で仕事をしてきており、たとえ効率を向上させるためであっても、従来の方法から、プロセスへの変更が多数伴う新しい方法に変えるのは難しいのです。

ところが、この心配は杞憂だったことが幸運にもわかりました。我々の製品ユニットの一部 (約 25%) は、既に VS2008 タイム フレームの間に TFS を他に先駆けて導入しており、その経験を活かして改良を加えたのです。ドッグフーディングのための彼らの熱心な取り組みが最初にあったため、その他の組織も 2、3 か月前に簡単に切り替えられました。大量のソース コードをすべて文字どおり 2、3 日のうちに新しいプロジェクトに移行してビルドしました。この間、多数の開発者がコード ストレージを扱いやすくなるように、規模に関する改良をいくつか特定して実装しました。この改良は、最終的にはお客様にも同様にメリットとなるはずです。

さらに、現在は TFS を使用してバグや機能を追跡し、Visual Studio 製品ファミリの一部として出荷されるチーム エクスプローラの要素を使用しています。これは、前のバージョンの VS 開発で先駆者のドッグフーディングが実施されたもう 1 つの領域です。そのため、組織の最終的な移行は同様にスムーズに行われました。結果をまとめると、今はコード、機能の計画、およびバグの追跡をしっかりと関連付け、従来のものよりはるかに優れたレポート作成サービスを活用できます。次期製品サイクルのライフタイム管理に対して私個人を含めて我々が今後節約できるコストは、計り知れないものになるでしょう。TFS はそれほど便利なのです。

SxS ( Side-by-Side )

開発製品自体を使って次の製品を開発しようとするには、当然ながら、ユーザーがインストールするように製品をインストールできる必要があり、その新しいバージョンが、既にコンピュータにインストールされている可能性がある以前のどのバージョンの製品とも干渉しないで動作する必要があります。この目標は、"Side-by-Side" または略して "SxS" と呼ばれます。これには、再バージョン管理やレジストリ エントリの変更が多数と、ハードコーディングされた必須のアセンブリ参照の処理がいくつかとその他もろもろの作業が含まれ、その後無数のテスティングを繰り返すことになります。製品サイクルの間、文字どおり数千個のコンポーネントを変更する必要があり、すべてはさまざまなチームから集められます。かつてこの作業は、ベータ版のマイルストーンに達するまで完了できないのが通例でした。ベータ版までは機能のコーディングに全力を傾け、それ以外の時間を取れなかったためです。しかし、SxS 作業を遅らせることは、我々が好むことではありませんでした。ユーザーがベータ版をインストールした場合、ベータ版のアンインストール後に以前のバージョンを修復する必要がある問題が発生し、解決に手間取ることがあったのです。これに加えて、製品サイクルの初期段階の機能を追加したために、いっそう "SxS の負債" を被り、既に進行中の SxS 作業があっても、やり直す必要があることがたびたびでした。

そこで、この落とし穴を避けるため、MQ でこの問題に真っ向から取り組むことを決めました。率直に言うと、これほど性急に取り組むには課題が大きく、我々は皆確実に深夜残業と週末出勤を経験しましたし、作業のスピードアップを実現するツールの再作成を求められるプロセスに多数遭遇しました。しかし、次期バージョンの機能のコーディングを開始する前に、この SxS 作業を早期に行うための時間を作ったことで、既にインストールしてある VS2008 を犠牲にせずに我々自身の製品をドッグフーディングできただけでなく、ベータ版利用者の皆さんがインストールとアンインストールを格段に高品質で実行できるようになり、ひいてはベータ版の利用環境が向上して当社へのフィードバック内容も充実することになるでしょう。

今後

今回の投稿はここまでです。私たち全員に大いに価値となる結果をもたらすはずの、ハードですが意義ある作業に関するまとめでした。ところで、私は今、コードの記述に関する別のブログ記事に取りかかっています。前回と違い、今回は既に本に書かれた内容でないとよいのですが ()。2、3 日中に投稿する予定です。

次回をお楽しみに。

  --Matt--*

VB チーム

投稿 : 2008 年 3 月 28 日 11:46 AM

分類 : Matt Gertz

VB チームの Web ログ - https://blogs.msdn.com/vbteam/archive/2008/03/28/milestone-quality-dogfooding-matt-gertz.aspx (英語) より

Comments