Support retrieve for direct-change validation

We use developer sandboxes for "scratch orgs" , and deploy changes from a develop branch, to a staging branch, to the master (production) branch.

Each of these branches are aligned with long-lived sandboxes or the production org.
Our policy is to route all changes from developer sandboxes, and to bring the changes through develop to staging and then to production. -- However, the Salesforce environment makes it easy to break the "source-first" policy, and, real life, there is a real danger that deployments to staging or production will overwrite important, direct changes that are not under version control.
A useful procedure would be to generate the deltaDeployment, and then retrieve the components we are about to change, to see if there is any unexpected changes. -- If we retrieve the deltaDeployment components and compare those components to the delta tag, the components should match. -- If the components do not match, we can pull the andon cord, fail the process, and alert the process administrator. -- Using the deltaDeploy for this check is especially useful, since it limits the scope of change to the components we are about to update. -- Currently, the deltaDeployment manifest uses wildcards wherever it can, and lists explicit members when it cannot use wildcards.

If the deltaDeployment manifest used explicit members for each type, then we could use it to "look before we leap".

Hi Ted,

as per what I understood, if the package.xml used explicit members it would help you to identify the unexpected changes only in the scope of the changes.

This behaviour is configurable, if you take a look to the config file config/packageConfig.json you can find an example of how the CustomObject section is configured:

 "objects": {
    "xmlTag": "CustomObject",
    "acceptsAsterisk": false,
    "extension": ".object"
 },

This configuration teaches deltaDeployment to:

don't use asterisk
go through all the *.object files in the directory objects and add them as members.

You can configure the entities you want be able to spot the unexpected changes in a similar way, just change de extension. Once you have the new configuration json file, i. e. config/packageConfig-enforceMembers.json, you can call the the task like this:

<deltaDeployment deltaFolder="delta"
    previousDeployment="last-deployment"
    configFile="config/packageConfig-enforceMembers.json" />

I hope I understood your scenario correctly and this change in the configuration helps you.

amguerrero / sfdc_ant_tasks

Support retrieve for direct-change validation #5