Deployment Automation with the Ant Migration Tool

Within the Salesforce framework, there are several tools and processes for migrating changes from one development environment to another and to deploying to a production organization, each having its advantages and restrictions. The most flexible tool is the Migration Tool. It is Java/Ant-based and allows the migration of metadata between unrelated organizations. The tool has no graphical user interface and needs installation outside of the familiar Salesforce environment.

In order to run deployment operations from the command line, you need a “” and a “build.xml” file. The “” file mainly stores information about the user access to the environment. Within the “build.xml” file, you can use commands like <sf:describeMetadata> (retrieves a list of metadata types enabled for your organization) or <sf:listMetadata> (retrieves specific property information for the individual metadata types).

These two commands can be used to review all the metadata components in your org and decide more specifically on your further deployment procedure. They can be consulted as a basis to create a “package.xml”.

The “package.xml” file is a project manifest that lists all the components to be retrieved or deployed. To delete files, you need to create a manifest that is called “destructiveChanges.xml”. The format of the delete manifest is the same as “package.xml”, except that wildcards are not supported.

To download metadata type components into a set of local files use <sf:retrieve> or <sf:bulkRetrieve>. The <sf:deploy> command then allows you deploy components to another environment.  A single build.xml can be created to carry out the entire deployment process as described above: <sf:describeMetadata>, <sf:listMetadata>, <sf:retrieve>, <sf:bulkRetrieve> and <sf:deploy>. Thus, the automated generation and formatting of the required files “package.xml” and/or “destructiveChanges.xml” are induced in the “build.xml” as well. Our internal tool processes the following steps:1.     Description of metadata and generation of a “package.xml” considering child objects and metadata exclusions2.     Retrieving of metadata from the org specified to local directory.3.     Reading out folder and file names from local directory.4.     Creating change set as xml (package.xml / destructiveChanges.xml)5.     Deploying changes to new environment. For further information on the usage of the Migration Tool, see the Migration Tool Guide.