Since the Ant Migration Tool is being retired, my team needs to move our legacy deployment scripts to the Salesforce CLI (sf). We have a lot of custom XML manipulation in our current Ant build.xml. Is there a way to replicate the "Selective Retrieval" of the Ant tool using 'sf project retrieve start', and how do we handle 'destructiveChanges.xml' in the new CLI-driven DevOps flow?
3 answers
The transition to Salesforce CLI is actually a huge upgrade in terms of speed and flexibility. Instead of manually editing 'package.xml', you should move toward a "Source Format" (sfdx-project.json). For selective retrieval, use the -m (metadata) or -p (sourcepath) flags in the sf project retrieve start command. For destructive changes, the modern way is to simply delete the file in your local source and use sf project deploy start. The CLI tracks the deletions and handles the 'destructiveChanges.xml' generation for you behind the scenes. It's much less error-prone than the old Java-based Ant tool.
Are you planning to use the new "DevOps Center" alongside the CLI, or are you sticking strictly to command-line scripts? If you're building a CI/CD pipeline in GitHub Actions, the CLI's '--json' output makes it significantly easier to parse results and trigger Slack notifications compared to the old Ant logs.
You can still use a 'package.xml' with the CLI if you prefer using the -x flag. It’s a great "middle ground" while your team gets used to the new command structure.
I agree with Nancy. We used the -x flag for the first two months of our transition. It allowed us to keep our old manifests while we learned the new 'sf' syntax.
Charles, we're definitely looking at GitHub Actions. The '--json' flag is a game changer for our automation! Dorothy, thanks for the tip on 'sourcepath'. I was worried I'd have to keep a giant 'package.xml' updated for every small change, but being able to just point to a folder/directory makes our feature-branching strategy so much more manageable. The migration seems a lot less daunting now.