Making Upgrades Less Painful †
要約 †
インストールのときと同じで、アップグレードの場合も、つらさを和らげる方法がいろいろある。
Choices for Painless Upgrades †
痛みを和らげるために開発チームが考慮すべきことを、以下にまとめた。
Number and Timing †
あまりにも頻繁にリリースすると顧客は追いつけないし、あまりにも間があきすぎると逆に不安になる。
アップデートの頻度やタイミングに注意しよう。
Upgrade Readiness †
11章で説明したこと（ディスクの空き容量チェックなど）に加えてさらに、現在インストールされているバージョンの状況（オプション機能の設定など）も調べよう。
それに基づいて、適切なアプローチを選ぶ。
Data Migration †
バージョンaのデータを受け取って、バージョンb用に変換する。言うだけなら簡単だし、実際簡単なのかもしれない。でも、現実の世界では、顧客の環境はいろいろ複雑なものだ。
データベースのスキーマが変わっていないのであれば、移行にはそれほど手間がかからないだろう。もし顧客がスキーマを変更していた場合は、その変更に対応する手を考えなければいけない。
顧客側で変更した部分はぜんぶ顧客側で何とかしてもらえる（変更箇所とそのデータをエクスポートしてからアップグレードし、そして変更箇所を書き戻すなど）のならそれでいいが、断られた場合は、この作業をするツールを作る必要があるだろう。
※ このへん、もう少し詳しくいろいろ書いてあるので、あとで見直しましょう（すみません。まとめきれなかった…）
Upgrade Configuration and Customization Information †
かつてMicrosoft Officeのアップグレードをしたとき、手元で変更したいろんな設定がぜんぶ消えてしまっていて非常にいらついた。君たちにはそんな間違いを犯してほしくない。ユーザーの設定も含めてきちんとアップグレードしよう。
Previous Versions †
データのマイグレーションにおける大きな問題のひとつは、いま顧客が使っている古いソフトウェアのバージョンがすべて同じとは限らないということ。複数の旧バージョンからのアップグレードを考慮しなければいけない。
基本的な戦略は次の二通り。
- 過去のすべてのバージョンからの、直接のアップグレードパスを提供する
- 過去のバージョンのサブセットからのアップグレードパスを提供する
- それ以外のバージョンを使っている人には、まずサブセットに含まれる直近のバージョンにアップグレードしてもらう
Coexist or Replace? †
新しいバージョンが旧バージョンを完全に上書きするのか、それとも共存させないといけないのか、その違いは大きい。
個人的には、上書きしてしまうことをおすすめする。まさかユーザーは、アップグレードのあとで旧バージョンを自分で削除しなければいけないとは思わないだろう。
コラム：It’s Easier to Say Yes than No †
TBD
コラム：Which Version Do I Use? †
TBD
担当者のつぶやき †
みんなの突っ込み †
