Update set strategy
Move changes between instances without collisions, missing records or last minute surprises.
Move changes between instances without collisions, missing records or last minute surprises.
- Update sets capture configuration, not data
- Preview before commit, always
- Small, short lived sets prevent collisions
- Batches handle dependencies between sets
How update sets work
An update set captures configuration records as you change them. Data is not captured, and neither are records outside the tracked tables, which is the source of most failed deployments.
Avoiding collisions
Collisions happen when two people change the same record in different sets. Keep sets small and short lived, merge only when necessary, and always preview before commit so you can see what will be overwritten.
What update sets miss
Plan for the gaps.
- Data such as choices you created through an import, groups, users and catalog variables in some cases
- Scheduled job run times and system property values that differ per environment
- Anything created in a different scope or a different application
- Attachments to records, unless explicitly captured
A workable process
One set per change or story, named with the story reference. Complete the set when the work is done, promote through test, and never reopen a committed set. For larger releases use a batch so dependent sets commit in order.