1.3.1 IBM i Master for Development?
Pros
- IBM i centric development. It's the model of choice for development shops with a major focus on IBM i.
- Existing IBM i change management systems may be used.
- Can develop without a connection to the Master System.
- It's the model you've been using.
- The LANSA development team has used this model extensively for developing LANSA in LANSA. (Not sharing the database with Repository Synchronization)
- All developers can be kept up to date using Repository Synchronization.
- Using Individual PC databases and Repository Synchronization together provides for some control over receiving other developer's changes as they are only received when connecting to Host Monitor.
Cons
- The 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)
- When the database is shared or Repository Synchronization are used, other developer's changes are updated into a developer's environment according to the schedule of the other developer. They are not obtained on demand. That is, the developer is not sandboxed.
- If the database is installed on each Developer PC then this requires more disk resource.
- Each Developer needs to install and update their Visual LANSA software.
Note: The redundancy afforded by having the Master System reduces the importance of backing up individual PC databases. If a PC database is lost, then only the changes up to the last check in will be lost. If developer's check in frequently then little is exposed.