Sustainingについて

Visual Studio 2008の開発も佳境に入り、部署の人間は皆忙しい毎日を過ごしています。 また、次バージョンと並行して、リリース済みの製品の品質保証に関わる作業が発生した場合、それに携わる人間、主にテストチームですが、は大わらわになることもあります。
私たちはそういった現行製品に対する作業を"Sustaining"とか"Sustained Engineering"と呼んでいるのですが、テストの観点から大きく2つに分けて考えています。

一つはVisual Studio以外の製品との互換性に関わるもの。 新しいOSもしくはOSのService Packがリリースされる際にはもちろんのこと、Visual Studio製品とつながりの深い製品、例えばSQL ServerやOfficeの新しいバージョン、Service Packに対しても互換性を確認する作業を行っています。 既にリリースされた製品に対する作業だからといって定型の単純な作業かというと決してそういうことはなく、確認対象中のアップデートされたコンポーネントがVisual Studioのある機能と特に依存性を持っているような場合には、慎重に確認を進める必要があります。 また、リソースの配分（時間、人員やテスト環境）にもいつも頭を悩ませています。 先だって公開されたWindows Server 2008 RC0のときもそうでしたが、限られたリソースをやり繰りして最大限の効果を発揮できるようにすることは非常に大切なテーマです。

もう一つはVisual Studio製品自体へのアップデート。 たとえば、Service PackやService Release、GDR、Hotfixのリリース作業がこれに当たります （ちなみに、GDRとはGeneral Distribution Releaseの略と聞いています）。 こういったものを"Servicing"と呼んでいます。
今年はこれまでにいくつかのService Release、GDR、Hotfixをリリースしてきました。 広範にわたる修正モジュールを含むService Packと違い、これらはある特定の機能の不具合の修正、新機能の提供などが目的となるので、一つ一つに対する作業量はService Packほど大きくはありません。 しかしながら、例えばセキュリティに関わる問題の修正等、緊急度が高いものについては、猶予がない状況で作業を行わなければならないこともあります。
また、Servicingの対象言語もVisual Studio製品では9ないし10言語、.NET Frameworkの場合は24言語にも及び、さらに、Servicingは平たく言えば一つの製品（モジュール）を出荷するのと同じですから、それに付随した作業、たとえばダウンロードセンターからのダウンロードやMicrosoft Update経由でのセットアップのテストなども必要になります。

このようにSustainingは単純なようでいて、それなりに労力のかかる作業です。 本社には専門のチームがあり、テストの計画や実行に加え、テストプロセスの効率化、Servicingモジュールの作成プロセスやセットアッププログラムの改善などを行っています。 私たち日本の開発チームも、そういった本社のチームや他の国の開発チームと連携してSustainingの作業に取り組んでいます。