ターキテクチャ上のリリース管理の影響 †
要約 †
リリース管理に必要なものを知ることで、リリース管理が簡単になるような選択を後押しすることでターキテクチャを改善できる。以下について考えてみよう。
- 全てを再生成しよう。リリース管理の最も重要なルールは、顧客に出荷されるものは全て(ソースコードから実行ファイルをビルドするように)導き出すか(Framemakerファイルからマニュアルを印刷するように)生成するかである。これは真面目に仕事をする人、特に彼らがマシンのバックアップを信用してない場合面白い振る舞いをする。かつて私の上司がIT部門を信用せずに全ソースツリーやビルドに必要なツール全てを複数のマシンにコピーしていて、IT部門が行ったバックアップが失敗していて彼女のバックアップに助けられ嬉しかったことがあった。
- 可能な限り既存のソリューションやインフラストラクチャを使おう。デプロイアーキテクチャのいくつかの面において、技術的な構成管理に関係する問題に対処できる可能性が高い。例えばMicrosoftはDLLとして詰めたコンポーネントや、関連する依存のために(悪夢のように)高価なインフラストラクチャを持っている。
- 可能な限り早く、ターキテクチャ上の情報をバージョン付けしよう。バージョン情報の必要性を感じたら、すぐに実行しよう。バージョン情報を後から組み込むのはコストが高くつらい。
- コンポーネントは依存関係を知っているべきだ。コンポーネントベースのシステムにおいて、あるコンポーネントは共に動作するコンポーネント群のバージョンを知っている必要がある。設定ファイルに保存された依存情報を処理する特別な依存チェックコンポーネントを介するのが恐らくデータドリブンなアプローチにおいて最も簡単な方法だ。 例えば、あるクライアントが未サポートのサーバに向けられた場合、完全に失敗とする代わりにクライアントはユーザに通知し、理想を言えば状況を正す方法を提供できる。
- メッセージやプロトコルはバージョン管理すべきだ。コンポーネント間で送信されるメッセージをバージョン管理することで、内容や処理ルールの変更が管理できる。
- データベースやデータベース内のテーブルはバージョン情報を持っているべきだ。これを行う方法の一つは、スキーマ内の各テーブルのバージョン識別子を含むシステムテーブルを作成することである。アプリケーションの必要に応じてテーブル内の特定カラムのリリース情報を提供するよう拡張できる。バージョン情報によりフィールド内をスキーマをアップグレードしやすくし、リリースされたスキーマの変更を検出可能にし、データベースに読み書きを行うコンポーネントがこれらを適切に行うのを保証する。
- アップデート可能なコンポーネントはバージョン管理すべきだ。バージョン管理することで、技術サポートの組織は顧客の問題に応じてコンポーネントを更新すべきかをすぐに評価できる。また部分インストールやパッチリリースをシンプルにする。
- 内部コンポーネントは、必要とする外部コンポーネントのバージョンを理解する必要がある。もしシステムがSolaris 2.8を必要とする場合、それをチェックする。Windows XP上で動いているシステムに問題を抱えた場合、それをチェックする。
- 全てのバージョンの成果物はバージョン情報を取得できる提供がなければならない。これにより顧客に対して技術サポートを可能にし、顧客セルフサービスや自動ソフトアップデートの基盤になる。
- パッチのテストやサポート影響に注意しよう。コンポーネントを作成し、前バージョンのサポートおよび後方互換性を提供するのが増えるにつれ、テストや検証の複雑さは指数関数的に増大する。後方互換性をサポートできるからといって、それをしなければならないと考えてはならない。
担当者のつぶやき †
みんなの突っ込み †
