1.3.3 開発用Windowsマスター
長所
- Windowsを中心としたチームの開発。主にWindowsに焦点を当てる場合の開発モデル選択肢。
- 既存のWindows変更管理システムやバージョン・コントロール・システムの使用が可能。
- VCSマスター・システムに接続せずに開発が可能。
- LANSA開発チームではLANSA内でのLANSA開発にこのモデルを利用。
- 開発者はリポジトリを更新する時期や更新箇所、どのオブジェクトにするかまで選択することが可能で、受信するLANSAオブジェクトの更新を完全に開発者がコントロールできる。開発者の意思表示や合意がない限り、開発環境は変更されない。つまり、開発者は他の開発者からサンドボックスにより守られる。
- セキュリティとタスク追跡は無効になり、代わりにLANSAオブジェクトへのコントロール・アクセスのVCSメソッドを使用。例えば、VCSがオブジェクトのチェックアウトを要求し、その際に限定された権限を求めることが可能。
- システム・データはVisual LANSAにより管理され、VCSマスターにチェックインされた別の開発者が加えた変更とともに、VCSマスターから受け取ることもできる。
- VCSマスターが提供する機能により、開発環境の性能を拡張できる。例えば、分岐、マージ、ソース比較、パッチ、ラベル付け、バグ追跡統合など。
欠点
- バージョン・コントロール・システムを保守・管理する必要があり、十分な理解が必須となる。
- IBM i スレーブのインストール時とシステム・データの更新時は、VCSマスター・システムが使用出来る状態でなければいけない。(システム初期化と区画初期化)
- オブジェクトの修正(チェックアウト)許可を得る時と他の開発者がこの変更を使用できるようにする(チェックイン)時に、マスター・システムが使用できる状態でなければいけない。
- 各開発者のPCに他のモデル以上のディスク容量が必要となる。
- 各開発者が各自Visual LANSAソフトウェアをインストールし、更新しなければいけない。