1 3 3 開発用Windowsマスター

Windows LANSA Installation

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ソフトウェアをインストールし、更新しなければいけない。

Ý1.3 開発モデルの選択