Conflicts between changeset commits
Summarize
Summary of Conflicts between changeset commits
In ServiceNow's Change and Deployment Management (CDM), multiple teams often work simultaneously on configuration data, resulting in numerous daily changes. Because conflicting changes can occur when different users modify the same configuration items, CDM manages commits and snapshots to detect and block conflicting changesets. When conflicts arise, users are notified to help resolve them effectively.
Show less
Important: Starting with the Washington DC release, DevOps Config is being prepared for future deprecation. It will no longer be installed on new instances but will continue to be supported.
How Conflicts Occur and Resolution Options
Every commit attempt triggers a conflict check against earlier commits. If conflicts are detected, users can either:
- Attempt to keep some changes by resolving conflicts.
- Discard all conflicted changes and start fresh with a new changeset.
To avoid losing work, it is recommended to copy large changes to a text editor before closing a conflicted changeset.
Best Practices to Avoid Conflicts
- Keep changesets open only briefly. Close and reopen a new changeset after gathering necessary information or research.
- Coordinate with coworkers to prevent simultaneous edits to the same configuration items.
Types of Conflicts
Conflicts typically involve configuration data items (CDIs) and can arise from various scenarios:
- Conflicting commits: Another user’s earlier commit conflicts with your changes.
- Stale data: The CDI’s value changed in another changeset, or the item was removed from a collection or deployable elsewhere.
- Data corruption: Incorrect modifications in the data table cause references to previous versions to be invalid or superseded.
- Changed parent: The parent of an item was deleted or renamed in another changeset, orphaning your item.
- Changed parent/child relationship: New items were added to a parent by another changeset while you modified the parent.
- Changed references: Items included in collections or deployables elsewhere cannot be deleted or altered.
- Duplicate items: An item with the same name already exists.
- Invalid includes: Components or collections referred to were deleted or renamed, or their descendants are already included in other changesets.
What This Means for ServiceNow Customers
This conflict management ensures data integrity and coordinated development when multiple users modify configuration data concurrently. Understanding conflict types and best practices helps teams minimize disruptions, effectively resolve conflicts, and maintain smooth service delivery.
Service delivery can include multiple teams working at the same time on config data with potentially hundreds of configuration changes every day. Because changes can be in conflict with earlier changes by a different user, CDM manages commits and snapshots to block commits that conflict. You are notified of changeset conflicts to help you to resolve them.
When a conflict happens
Every time you attempt to commit a changeset, the system determines whether there are conflicts with other earlier commits. If the system reports a conflict, you can choose to attempt to keep some of the changes or discard all conflicted changes and start from a new changeset. For this reason, to ease the task of recreating your work, you might copy-paste larger changes to a text editor before closing a conflicted changeset.
How to avoid conflicts
- Try to keep a changeset open for a brief period. If you need to do research, close the changeset and start a new changeset after you have the information.
- Coordinate your code editing tasks with coworkers. This enables you to avoid updating the same configuration item at the same time.
Types of conflicts
- Stale data in your working changeset
- The value of the item was changed in another changeset.
- The item is no longer included in a collection or deployable in another changeset.
- Data corruption caused by an incorrect change in the data table: The newly added item in your open changeset was modified in the data table to incorrectly refer to a previous version. The item in your open changeset was superseded by a change in the data table. The updated or deleted item in your open changeset was incorrectly modified in the data table to not refer to the previous version.
- Changed parent
- The item is an orphan because its parent was deleted or renamed in another changeset.
- Changed parent/child relationship
- New items were added in another changeset while you made changes to the parent data item.
- Changed references
- The Item was included in a collection or deployable in another changeset.
- The item cannot be deleted because it is included in a collection or deployable in another changeset.
- Duplicate
- An item with the same name already exists.
- Invalid includes
- The component or collection to which the include referred was deleted in another changeset.
- The component or collection to which the include referred was renamed in another changeset.
- A descendent of the component to be included is already included in the collection in another changeset.