Skip to main content
All CollectionsChange Management with Salto
Detecting and resolving conflicts
Detecting and resolving conflicts
Support avatar
Written by Support
Updated over 11 months ago

Configuration conflicts may arise when simultaneous changes are made to the same configuration element. Consider the following scenario:

  • 2 admins, each working on their own sandbox on a different feature.

  • The configuration in both sandboxes and the integration is identical.

  • When ready, changes from each of these sandboxes are promoted to an integration environment.

Now, imagine both features require modifications to the same configuration element, 'E’, with an initial value ‘V’. The first admin changes the value of ‘E’ from ‘V’ to ‘V1’ and successfully pushes this change to the integration environment. Concurrently, the second admin changes the value of ‘E’ from ‘V’ to ‘V2’. Upon attempting to push this change, a conflict arises since the current state of ‘E’ in the integration environment is no longer ‘V’, but rather ‘V1’.

To resolve this conflict, there are several options:

  1. Choose the Second Admin's Value (V2): This choice updates the element from the existing value "V1" to "V2," reflecting the second admin's changes.

  2. Maintain the First Admin's Value (V1): Opting for this maintains the first admin's change, effectively disregarding the second admin's alterations to "E."

  3. Introduce a New Value (V3): Here, a new value "V3" is manually assigned to "E," updating it from "V1" to this newly decided value "V3."

With Salto, configuration conflicts are seamlessly detected during the deployment process. If any conflicts are present, the deployment transitions into a conflict resolution stage. In this crucial phase, users must address and resolve all conflicts before they can proceed with the deployment.

During this stage, users are presented with a comprehensive table detailing all the elements involved in the deployment. This table is organized into three distinct tabs for ease of navigation and clarity:

  1. Open Conflicts: This tab contains a list of all elements that currently have one or more unresolved conflicts.

  2. Resolved Conflicts: Here, users can find a list of elements where all conflicts have been successfully resolved.

  3. Complete Deployment Elements: This tab shows every element involved in the deployment, providing a full overview.

When selecting a deployment element with conflicts, a 'resolve' button will appear next to each conflicting value.

If a conflict involves a simple value, such as a single-line string, clicking on the 'resolve' button will prompt a window. This window enables the user to select between their own changes, the existing changes in the target, or to manually edit the value.

When encountering conflicts within a multi-line string, such as a script, clicking the 'resolve' button launches a three-way merge editor. This editor is divided into three sections:

  1. The top-left section displays a read-only diff outlining the user's modifications.

  2. The top-right section presents a read-only diff highlighting the changes made in the target environment.

  3. The bottom section showcases the combined result. Here, the user must manually resolve each conflicting line by selecting either their version, the target version, both versions, or by editing the content directly.

After resolving all conflicts, the 'Apply Conflict Resolution' button becomes active. Clicking this button recalculates the deployment preview, incorporating all the resolutions made.

Did this answer your question?