kkamegawa's weblog

Visual Studio,TFS,ALM関係のことについていろいろと書いていきます。Google Analyticsで解析を行っています

テスト後のリリース管理

テスト完了してリリースすることになります。LinuxとかWindowsといった、カスタマイズって設定変更のことじゃないの?というようなことを思う人もいるでしょう。私も昔はそうでした。「カスタマイズ?客ごとに違うモジュールとか作ってたら、絶対管理できないし、テストも大変じゃない。そんなのできるわけないでしょ」と。
しかし、業務アプリケーションだとカスタマイズはモジュールの差し替え、データベーススキーマの変更などなど当たり前のようにやっているようで、ほんとに驚きました。データベースのスキーマにそのための予備みたいな項目があったり。

図にするとこんな感じ。Linuxなどの分散開発と違うのは、一度分岐すると絶対に本流に戻ることがない(ことが多い)。現代的なJavaとか.NETなどの開発環境だったらきれいな解決方法があるかもしれないけど、昔はそうでもなくてねぇ。
で、作ったモジュールがどのお客様用かちゃんと管理しなくてはならないし、「なぜこの開発を行ったのか」という情報と、「どういうテストしたのか」という情報も管理しなくてはならないです。
ちゃんとしたソース管理されていれば、それぞれのお客さんごとにブランチ切って、共通部分になっているところでバグ修正した時にはマージしなければなりません。そういうのは人間がやると絶対失敗するので、ちゃんとしたソースコード管理ツールでテストケースとともに管理しましょうと。
昨日書いたテストケース管理をExcelでやるみたいな話とも関連しますけど、こういうのはできれば別のツールでバラバラで管理するのではなくて、それぞれ関連付けて管理しないと「あの修正がこちらに反映されていない」とか、「反映してはいけない修正を反映した」とか「テストケースが漏れていた」とか「起動できないモジュールをリリースしてしまった」とか、ざらに発生します。
百程度のモジュール数であれば一人で管理することもできますけど、1000超えたり、複数のチームが分散していると隣の人は何する人ぞで絶対にミスも起きます。なので、継続的インテグレーションでインターフェースを変えるような修正を行った場合は特に、自動ビルド、完全じゃなくても自動テストをある程度やる必要があると思います。
Team Foundation ビルドを使用した常時結合