nicholasdsi-tecex
commented
6 months ago Does this idea include performing conflict resolution on sync? We've found changes being overridden by syncs in different sandboxes even if the changes in the sandbox have been made after a promotion. Example: Two devs each have their own environments. Dev A is working on a larger project adding new fields and flows for Account related processes. Dev B has had a quick request to add a related list to an Account page layout.
Order of operations: Dev A begins working in Sandbox A on Monday, adding new fields, updating layouts and working on a flow to add logic to the fields. They need a week to make and test all the changes. Dev B works in Sandbox B and on Wednesday gets a request to add a related list to one of the Account page layouts that Dev A is also working on. Dev B creates and promotes a work item for a quick Account page layout change. Dev A on Friday is now done with their changes and they would like to promote their changes. If they sync Sandbox A, then the changes from Sandbox B that were promoted will be brought into Sandbox A on the layout will override all the other changes that Dev A made in their sandbox without warning. There is no conflict resolution when syncing sandboxes like there is when performing a promotion.
In this case, the related list request was urgent and needed to go live quickly. If Dev B had to promote without syncing, they would need to choose which changes to keep in the next environment but they might miss other changes. If Dev B sync'ed before creating a work item, then the changes from Dev A would override the layout that Dev B was working on. Dev A couldn't even add the related list to their layout and promote that because they would have the new fields in the layout which wouldn't exist in the next environment.
Users can sync changes between development environments before changes are promoted to first pipeline stage