Calling for all subsets to be checked in to facilitate migration can be very costly and nonproductive. Migration can take place while subsets are checked out.
Consider checking out a subset with the root subject area for Modify and the databases for Delete before any other subset is checked out. You can then migrate the data-related objects (entity types, attributes, relationships, and so forth) by overriding the subset, and then re-checking out the subset.
You can use this same technique for other shared objects. If shared objects are being changed in one model, you should check out them for Modify or Delete in all other models but not download them. This protects them from being changed and/or ending up in another subset for modify or delete. When it is time for them to be migrated, you can override the protective subsets and the migration can proceed without conflict.
When a mass check-in is required, spread out the uploads over time so everyone does not try to upload at the same time (such as at the end of the business day). Another method to avoid contention on a mass upload, is to have everyone using the model submit their upload in batch with the same job name. This runs the uploads sequentially and avoids conflicts.
Following a mass upload, a mass download is usually needed for the next day. To avoid everyone attempting a download at the same time, define subsets in advance and submit the downloads with the same jobname to process overnight. This sequentially downloads the subsets.
|
Copyright © 2013 CA.
All rights reserved.
|
|