We are in the process of setting up ant to deploy our configuration changes across our environments to production. We are using changesets at the moment. We use standard objects, custom objects, profiles, workflows, lead assignment rules, ques, layouts, email templates and lead sharing rules at the moment. What should be the sequence i should follow on the package.xml so that i do not get dependancy errors like custom objects complaining workflows not found, or letter heads complaining logo file not found etc? What is the sequence or dependancy check you guys do to deploy configuration changes to another sandbox or production? Buyan
The order of the elements in a single package.xml are irrelevant. The system intelligently reorders dependencies so that the elements are deployed in the correct order. Occassionally, the system doesn't get it right, though, in which case the order of the package.xml elements will not help you at all. For those situations, you must instead deploy multiple package.xml files and directories independently. Generally, the order within each package will not matter, but packages that refer to elements in other packages will need to be deployed after the elements they refer to.
I strongly encourage you to start with Force.com Migration Tool Guide. For example page 15 provides the list of supported parameters when deploying with ANT, to name
pollWaitMillis (crucial when deploying a bigger package),
allowMissingFiles (useful when a file corresponding to an entry in
package.xml does not exist) and
The topic of deployments is broader and more interesting than just configuring ANT though. In my biggest project (thousands of components, several developers in a team) we built a plugin for Jenkins that automatically constructs
plugin.xml and related file structure for particular SVN revisions. This way:
- A commit to SVN triggers an immediate deployment to a dev sandbox and, if it fails, sends an email with list of problems to the team,
- It's possible to deploy a list of revisions (for example enclosing a single project) to any environment on demand, just with a few clicks,
- We're enabled to refresh a full-copy sandbox and deploy to it developed projects more often, as whole the process is largely automated,
- Most importantly: every change is really committed to SVN, as it's the only way to deploy things outside of developer sandboxes.
If you want to get your order right when deploying Salesforce metadata I would recommend reviewing the dependencies. There is no specific order however the Metadata has some bugs with regards to deploying some dependent items (e.g. approvals and approval actions) where these already need to have been deployed separately.
I recommend you look at Copado Deployer from the AppExchange (https://appexchange.salesforce.com/listingDetail?listingId=a0N3000000B3dgGEAR).
If you encounter errors in your deployment, Copado will give you tips to resolve your problems and achieve a deployment success quicker.
It also allows you to run automated Apex tests and schedule git back ups (re endrju's comment).
This videos might help you get started: http://www.youtube.com/channel/UC8te3UIYjrDftwNPx_5ZpYg
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <Package xmlns="http://soap.sforce.com/2006/04/metadata"> <types> <members>*</members> <name>CustomObject</name> </types> <types> <members>*</members> <name>StaticResource</name> </types> <types> <members>*</members> <name>ApexClass</name> </types> <types> <members>*</members> <name>ApexComponent</name> </types> <types> <members>*</members> <name>ApexPage</name> </types> <types> <members>*</members> <name>ApexTrigger</name> </types> <types> <members>*</members> <name>PermissionSet</name> </types> <types> <members>*</members> <name>Workflow</name> </types> <version>28.0</version> </Package>