We are trying to implement an automatic deploy from a Git repository to Salesforce. We have all the metadata in a repository and so far, we were able to deploy a subset of these metadata doing these operations:

  1. Create a folder to deploy
  2. Copy in the new folder a package.xml file
  3. Copy in the new folder the subset of the entities contained in the package.xml

The way we manage the 3th point is not really smart, as we need to duplicate the information held in the package.xml: we have a separate list of all the entities contained there and copy each one of them from the repository to the deploy folder.

Is there a better way to implement this task?

A possible solution would be to retrieve the entities form a sandbox, but we would rather pick everything from the repository.

We can work with both DX and the classic metadata structure.

| improve this question | | | | |
  • I assume you are looking for a way to handle point 3 without duplicating the info? Could you not use an XSLT to transform the package.xml into an Ant script that uses filesets to copy files from one location to another (where the file set content is derived from the package.xml detail)? – Phil W Apr 18 '19 at 22:44
  • Hi @PhilW , thanks! Your assumption is correct! I will try this approach. I wonder though if it is a "standard" procedure for people trying to implement CI with Salesforce. If you have some example or link to provide feel free to answer the question. – Andrea DL Apr 19 '19 at 15:53

Is there a reason not to use the standard SFDX push? The command line is simple. Use this one if your meta data is in the SFDX "source" structure:

sfdx force:source:push -u alias

And if your meta data is in the classic meta data structure use:

sfdx force:mdapi:deploy -u alias

Only the latter requires the package.xml to be in place IIRC.

Either of these is good if you have a local clone of your repo and a checkout of the branch you want to deploy from available in your file system.

| improve this answer | | | | |
  • I believe these commands are useful per se when one deploys in a Test environment. The second works for Production as well, but in some scenarios one could have a set of entities to deploy that are involved in a functionality, like a package of entities that are often deployed and could change as the development progress! In this case it would be useful to have a way to pick these entities and deploy them running the tests! – Andrea DL Apr 29 '19 at 8:35
  • Note that if you have a tracking org, like a scratch org, then force:source:push will perform this incrementally anyway. – Phil W Apr 29 '19 at 8:47

Disclaimer: I work for Gearset

If you're looking to save a bit of time and automate this process, there are a handful of third-party paid-for tools that can help you here, of which Gearset is one. It'll show you a diff between git branch and org, and automatically build a package.xml and package.zip from your selections, then push it to the target org. It'll also help you set up a CI job for you that'll monitor a git branch and automatically deploy it to a target org when any changes are detected. It also works with DX and Ant-format metadata. There's a free 30-day trial, no managed packages to install, don't need to give us payment info up-front, etc., so feel free to take it for a spin.

| improve this answer | | | | |

Not the answer you're looking for? Browse other questions tagged or ask your own question.