めっちゃシステムな話。
サーバーのバージョンアップ作業の改善案。
一般人は意味プーな内容だと思うので、特に見なくてもよいかと。。
＜問題＞
顧客が大量にいて、同じシステムを導入しているはずなのに、
サーバーへのデータ移行、バージョンアップ作業に非常に時間とられる。
必要な処理だけど、生産的な作業ではない。はっきりいって。
＜改善策＞
1．ディレクトリ構成
基本はデータの上書きなのに、データの提供のディレクトリ構成が
サーバーの構成と全然一致していない。サーバーの標準構成をつくり、バージョンアップデータは
それに基本的に上書き＋環境の違いはバッチファイルでフォルダ構成を変更すればいい。
2．サーバー環境の違い
こちらは、OSの違い（WinとUnix等）やミドルウェア、DB等の違い。
それぞれに異なるプログラムを作成する必要がある（コマンド、プログラミング言語が異なるから）。
また、顧客の規模によっても異なる。DBやAPサーバーの数。
顧客の環境によっても。親会社のハード入れたい、とか、セキュリティ上他と同じ構成にしたくない、など。
セキュリティで他構成と同じに出来ないのは仕方ないとして（バージョンアップ作業時のトラブルリスクを多く抱えることを
認識しているなら）、それ以外は10程度にパターン化出来ると思われる。
3．差分データ管理方式
差分データ管理とは、出荷したバージョンで更新されたファイルのみをデータとして載せる管理をすること。
Ver1.1だとAファイルがあるが、1.2だとAファイルがない、というような形。
この場合、1.2のみ更新するとAファイルが最新の情報でなくなったりするため、各バージョンのマージ
（整合性を取るために差異を埋めていく）作業が必要。
現在ならDVD-ROMに大量データ詰め込めるし、よっぽど大きなシステムのファイルでない限り、
それなりの量は管理できるはず。
それがなくても、バージョンの幅を選択するだけでマージしてくれるようなツールがあってもいい。
（出来るだろう）
4．例外作業の存在
新しい仕組みになったために、ファイル構成の変更、参照データの変更等が現れ、そのために
お客さんの環境に沿った環境設定（変数の入力）が必要になる。
基本、同じ構成にしてしまえば問題ないと思われる。
5．バージョンアップによるデグレード
これはある程度出てくる。ちゃんとしたところならば、すべて修正箇所をソースレベルで文書化でもしている
のかもしれないが、それを全部見てデグレードつぶしも無理だろう。
そもそも、サーバーごと提供してしまえば、上記のようなことをすべて包括したソリューションを提供可能ではないだろうか。。
すでにソフト載っている製品を、サーバーごと売ってしまう。
後は標準のバージョンアップ作業を行うのみ。