Force.com Migration Tool Guide

Clouds with binary code floating aboveCloud with binary code floating above

No Results

Search Tips:

  • Please consider misspellings
  • Try different search keywords
PDF

Newer Version Available

This content describes an older version of this product. View Latest

Deploying Changes to a Salesforce Organization

The build.xml file specifies targets to retrieve and deploy. The following parameters may be set for each deploy target:

Field Description
username Required. The Salesforce username for login. The username associated with this connection must have the “Modify All Data” permission. Typically, this is only enabled for System Administrator users.
password Required. The password you use to log into the organization associated with this project. If you are using a security token, paste the 25-digit token value to the end of your password.
serverurl Optional. The Salesforce server URL (if blank, defaults to www.salesforce.com). To connect to a sandbox instance, change this to test.salesforce.com.
pollWaitMillis Optional. Defaults to 10000. The number of milliseconds to wait when polling for results of the deployment. Note that deployment may succeed even if you stop waiting.
checkOnly Optional. Defaults to false. Set to true to check the validity of the deployed files without making any changes in the organization. This will not deploy any components or change the organization in any way.
maxPoll Optional. Defaults to 200. The number of times to poll the server for the results of the deploy request. Note that deployment may succeed even if you stop waiting.
deployRoot Required if zipFile is not specified. Specifies the root of the directory tree of files to deploy. You must define a value for either zipFile or deployRoot.
zipFile Required if deployRoot is not specified.. Specifies the path of the metadata zip file to be deployed. You must define a value for either zipFile or deployRoot.
singlePackage Optional. Defaults to false. Declares that the zipFile or deployRoot parameter points to a directory structure with a single package, as opposed to a set of packages.
allowMissingFiles Optional. Defaults to false. Specifies whether a deploy succeeds even if files that are specified in package.xml are not in the zip file. Do not use this parameter for deployment to production organizations.
autoUpdatePackage Optional. Defaults to false. Specifies whether a deploy should continue even if files present in the zip file are not specified in package.xml. Do not use this parameter for deployment to production organizations.
ignoreWarnings Optional. Defaults to false. This setting indicates that a deployment should succeed even if there are warnings (true) or that one or more warnings will cause the deployment to fail and roll back (false). If there are errors, as opposed to warnings, the deployment will always fail and roll back.
purgeOnDelete If true, the deleted components in the destructiveChanges.xml manifest file aren't stored in the Recycle Bin. Instead, they become immediately eligible for deletion.This option only works in Developer Edition or sandbox organizations; it doesn't work in production organizations.
rollbackOnError Optional. Defaults to true. Indicates whether any failure causes a complete rollback (true) or not (false). If false, whatever set of actions can be performed without errors are performed, and errors are returned for the remaining actions. This parameter must be set to true if you are deploying to a production organization.

In earlier versions of the Force.com Migration Tool (Spring '14 and earlier), this parameter is ignored in build.xml and Salesforce behaves as if this parameter is set to true.

Note
runAllTests Optional. Defaults to false. For a deployment to a production organization:
  • If set to false (default value), all tests except tests that originate from installed managed packages are run after deployment.
  • If set to true, all tests including tests that originate from installed managed packages are run after deployment.
For a deployment to sandbox:
  • If set to false (default value), no tests are run.
  • If set to true, all tests including tests that originate from installed managed packages are run after deployment.
runTest Optional child elements. A list of Apex classes containing tests run after deploy. If any of these tests fail, the deployment is rolled back and no changes will be made to your organization.
trace Optional. Defaults to false. Prints the SOAP requests and responses to the console. Note that this will show the user's password in plain text during login.
logType Optional. The debug logging level for running tests. The default is None. Valid options are:
  • None
  • Debugonly
  • Db
  • Profiling
  • Callout
  • Detail

The Force.com Migration Tool ignores any files or folders with a name starting with a period (.) or ending with a tilde (~) when deploying files. Some source control systems, such as Subversion, create files or folders with names starting with a period. These files can cause issues during deployment to Salesforce, so the Force.com Migration Tool ignores them.

Note

The Force.com Migration Tool comes with a sample build.xml file that lists several deployment targets. You will want to create your own custom targets using the sample targets as starting points. A description of the sample targets follows:

  • deployUnpackaged — deploys unpackaged components specified in the target.
  • deployCode — deploys the contents of the codepkg package specified in the target.
  • undeployCode — deletes classes and triggers in the removecodepkg directory specified by the destructiveChanges.xml manifest. This file is similar to package.xml, but lists components to be deleted. For more information, see Deleting Files from an Organization.
  • deployCodeFailingTest — deploys code that fails testing requirements, strictly for demonstration purposes.
  • deployCodeCheckOnly — verifies that deployment will work, but does not deploy any components.