1.3.3 Windows Master for Development?

Pros

• Windows centric team development. It's the model of choice for development shops with a major focus on Windows.

• Existing Windows change management systems and version control systems may be used.

• Can develop without a connection to the VCS Master System.

• The LANSA development team is using this model for developing LANSA in LANSA.

• Developers can choose when to update their Repository and what part of it, down to an individual object. The developer is in complete control of what LANSA Object updates they receive. Nothing effects their development environment without their express and precise consent. That is, they are sandboxed from all other developers.

• Security and Task Tracking are disabled and are replaced by the VCS method of controlling access to LANSA objects. For example, a VCS may require an object to be checked out and that object may have limited permissions on it.

• System data is maintained by Visual LANSA and can also be received from the VCS Master via alterations that have been made by another Developer and checked in to the VCS Master.

• The sophistication of the development environment is expanded to the extent that the VCS Master provides those features. Those features may include, but are not limited to, branching, merging, source comparison, patches, labeling, and bug tracking integration.

Cons

• A thorough understanding of the chosen version control system is required and it must also be administered and maintained.

• The VCS Master System must be available when installing the IBM i Slave and whenever system data needs to be updated. (System Initialization and Partition Initialization)

• The Master System must be available to obtain permission to modify an object (Check Out) and to make those changes available to other developers (Check In)

• Each Developer PC requires more disk resource than with any other model.

• Each Developer needs to install and update their Visual LANSA software