7

I am setting up a continuous integration for a team development process using GitHub and Ant (and eventually Jenkins) and have a problem with deploying to dev sandboxes to keep them in sync with Production:

How do you programmatically customize the Package.xml and the src/ folders to only include the metadata files that have changed in Production?

Our Production environment has over 5000 files so if I retrieve the entire metadata set from Production to the master branch, rebase the dev sandbox branch and attempt to deploy that to its dev sandbox, I hit the API limit for deploying metadata via the API. The metadata in Production changes both from packages deployed from sandboxes as well as from changes made directly in Production by Admins, so I cannot rely on combining all pushed metadata files and package.xml files.

1 Answer 1

2

try this, only generate package.xml for the files in the commit:

http://kevinbromer.com/2013/03/dynamically-building-package-xml

2
  • 1
    I would be careful with this. If your deployment fails after the commit, you could miss changed files in the next commit. ex. I check in FileA. Deployment fails (broke a test, deployment took too long, forgot a file, etc). I check in another file (TestA, FileB). Correct me if I'm wrong, but FileA would not end up getting deployed until it was changed again.
    – Rob Scott
    Commented Jun 3, 2013 at 17:21
  • 2
    That's correct. You'd want an additional script in the build that reverts your last commit file to its previous version in the case of a build failure. This only builds package.xml based on what files are in the commit listed from your previous commit to the most recent. If you reverted the last commit file to a previous version on build fail, you'd avert the issue you're describing. (EDIT: I should add, this builds from git commits, not from org changes)
    – kmb
    Commented Jun 3, 2013 at 20:48

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .