- edited description
Offer the possibility to log any metadata deletions to a destructiveChangesLog.xml
Hi Scott,
I’ve seen issue #1796 but here’s my take.
While it is somewhat mind-boggling to consider the full implications of destructive changes in a deployment lifecycle (cf. #1688), especially with SFDX source tracking, it would be great if there was a simple mechanism empowering the individual developer to keep track of deletions.
I’d like to keep track of metadata refactoring and resulting deletions in a destructiveChangesLog.xml, with the following basic assumptions:
- Usable with MDAPI or SFDX
- Usable with or without VCS
- The developer doesn’t necessarily have the right to migrate changes to upstream environments
Use cases:
- With VCS, the developer wants to consciously decide which destructive changes to include in his pull request (if any) by selectively promoting them from destructiveChangesLog.xml to an actual destructiveChanges.xml
- Without VCS, the developer wants to selectively promote destructive changes from destructiveChangesLog.xml to an actual destructiveChanges.xml for a specific deployment
Does it make any sense?
To facilitate the merge, I’d actually want the developer to include destructiveChangesLog.xml in the pull request so that I have an insight into deleted metadata and can re-evaluate at merge time whether the submitted destructiveChanges.xml (if any) makes sense. So under this idea, destructiveChangesLog.xml should not be edited.
Comments (4)
-
reporter -
reporter - edited description
-
reporter - marked as proposal
-
repo owner - changed status to duplicate
Duplicate of #1796.
- Log in to comment