[SalesForce] Customizing Package.xml for updating Sandboxes with Continuous Integration

We are using a very similar setup internally. What we have found works is that

1) All devs work in their own separate sandboxes.

2) All development is done in feature branches.

3) When work is ready for QA/Integration testing feature branches are merged into master.

4) Jenkins build runs whenever there is a commit to master and performs a deploy to the QA/Integration environment.

You may want to check out the Atlassian Guide for Setting up CI. They use Bamboo but most of the issues you will run into with maintaining your package.xml and keeping config changes in sync will be very similar.

Based on the discussion in the comments...

The problem appears to be with how the package contents was being passed to Salesforce. That is, it deployed when directly passed to the Metadata API via workbench as a flat structure, but was failing when the folder structure was included in the zip file.

As per the answer to Metadata Deploy - Package.xml Failure, the deployRoot folder structure needs to be:

+ src
|-- package.xml
  +-- classes
    |-- MyCustomWrapper.cls
    |-- MyCustomWrapper.cls-meta.xml

Try updating your sf:deploy in the build.xml with attributes for:

• pollWaitMillis="10000"

  The number of milliseconds to wait between polls for retrieve/deploy results. The default value is 10000 milliseconds (ten seconds). For long-running processes, increase this number to reduce the total number of polling requests, which count against your daily API limits.

• maxPoll="200"

  The number of polling attempts to be performed before aborting. The default value is 200. When combined with the default value of pollWaitMillis (10000), this means the Force.com Migration Tool will give the server process a total of 2,000 seconds (33 minutes) to complete before timing out. The total time is computed as 200 poll attempts, waiting 10 seconds between each.

This will increase the timeout duration.