Deploying a validation helps you shorten your deployment time because tests aren’t
rerun. If you have a recent successful validation, you can deploy the validated components
without running tests. You can deploy a recent validation with the <sf:deployRecentValidation> task.
A validation doesn’t save any components in the organization. You use a validation only to
check the success or failure messages that you would receive with an actual deployment. To
validate your components, add the checkOnly="true" parameter in your
deploy target (<sf:deploy>).
Before deploying a recent validation, ensure that the following requirements are met.
- The components have been validated successfully for the target environment within the last
four days (96 hours).
- As part of the validation, all Apex tests in the target
organization have passed.
- The overall code coverage in the organization is at least 75%, and Apex triggers have some
coverage.
The <sf:deployRecentValidation> task supports these
parameters.
| username |
Required if sessionId isn’t
specified. 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 if sessionId isn’t
specified. 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. |
| recentValidationId |
Required. Specifies the ID of a recent validation. |
| sessionId |
Required if username and
password aren’t specified. The ID of an active Salesforce session. A session
is created after a user logs in to Salesforce successfully with a
username and password. Use a session ID for logging into an existing session instead
of creating a new session. |
| 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. |
| 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. |
| 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. |
| 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. |
| 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. |
This example shows a target for deploying a recent validation. The value of
recentValidationId (sf.recentValidationId) is defined in the build.properties
file.
1<target name="quickDeploy">
2 <sf:deployRecentValidation username="${sf.username}" password="${sf.password}"
3 sessionId="${sf.sessionId}" serverurl="${sf.serverurl}"
4 maxPoll="${sf.maxPoll}"
5 recentValidationId="${sf.recentValidationId}"/>
6</target>
Support for <sf:deployRecentValidation> starts with
version 34.0 of the Force.com Migration Tool.
j