Hi Creative Thinker,
A common process for developing customizations with update sets involves moving changes from development to test to production instances:
- Create an update set on the development instance.
- Make customizations and changes on the development instance.
- Mark the update set as Complete.
- Log in to the test instance and retrieve the completed update set from the development instance.
- Commit the update set on the test instance, and test customizations thoroughly.
- If the update set has problems in the test instance, repeat steps 1 - 5 to develop the fix on the development instance with another update set.
- Log in to the production instance and retrieve the completed update set from the development instance. If the update set required a fix, retrieve both update sets.
- Commit the update set on production. If the update set required a fix, commit both update sets in the order they were made.
If your development environment consists of only two instances, you can combine your development and testing instances into a single staging instance. For example:
- Create an update set on the staging instance.
- Make customizations and changes on the staging instance.
- Mark the update set as Complete.
- Test customizations thoroughly on the staging instance.
- If the update set has problems, repeat steps 1 - 4 to develop the fix on the staging instance with another update set.
- Log in to the production instance and retrieve the completed update set from the development instance. If the update set required a fix, retrieve both update sets.
- Commit the update set on production. If the update set required a fix, commit both update sets in the order they were made.
To avoid transfer errors create only one update source record per instance source. Each update source must have a unique URL.
If the update set in the source environment has everything:
- You can export that update set as XML, and import it into the destination instance via Retrieved Update Sets.
- Once you do that, you can preview and commit it.
- You will get a "this record has a more recent update" error for all the items that went through with the first update set, You can either ignore these, or accept them all. It shouldn't make any difference since it's the same update you're applying.
If the update set in the source environment doesn't have everything:
You should look in other update sets and the "Default" update set to see where your updates went. Once you find them, you can either:
- Move them into a new update set and apply them (risky)
- Add each record that is missing into a new update set manually (time consuming)
Points to Remember:
Scheduled Jobs are not considered customization (you can tell based on the absence of the "update_synch" attribute on the table), and they are not captured in update sets.
Warning: Do not add the update_synch attribute to a dictionary record. When improperly used, this attribute can cause major performance issues or cause the instance to become unavailable. Adding this attribute is not supported.
