Force.com Apex Code Developer's 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

Understanding deploy

The deploy call completes successfully only if all of the following must be true.
  • At least 75% of your Apex code must be covered by unit tests, and all of those tests must complete successfully.
    Note the following.
    • When deploying to a production organization, every unit test in your organization namespace is executed.
    • Calls to System.debug are not counted as part of Apex code coverage.
    • Test methods and test classes are not counted as part of Apex code coverage.
    • While only 75% of your Apex code must be covered by tests, your focus shouldn't be on the percentage of code that is covered. Instead, you should make sure that every use case of your application is covered, including positive and negative cases, as well as bulk and single records. This should lead to 75% or more of your code being covered by unit tests.
  • Every trigger must have some test coverage.
  • All classes and triggers must compile successfully.

You cannot run more than one deploy Metadata API call at the same time.

The Force.com Migration Tool provides the task deploy which can be incorporated into your deployment scripts. You can modify the build.xml sample to include your organization's classes and triggers. The properties of the deploy task are as follows:

username
The username for logging into the Salesforce production organization.
password
The password associated for logging into the Salesforce production organization.
serverURL
The URL for the Salesforce server you are logging into. If you do not specify a value, the default is www.salesforce.com.
deployRoot
The local directory that contains the Apex classes and triggers, as well as any other metadata, that you want to deploy. The best way to create the necessary file structure is to retrieve it from your organization or sandbox. See Understanding retrieveCode for more information.
  • Apex class files must be in a subdirectory named classes. You must have two files for each class, named as follows:
    • classname.cls
    • classname.cls-meta.xml
    For example, MyClass.cls and MyClass.cls-meta.xml. The -meta.xml file contains the API version and the status (active/inactive) of the class.
  • Apex trigger files must be in a subdirectory named triggers. You must have two files for each trigger, named as follows:
    • triggername.trigger
    • triggername.trigger-meta.xml
    For example, MyTrigger.trigger and MyTrigger.trigger-meta.xml. The -meta.xml file contains the API version and the status (active/inactive) of the trigger.
  • The root directory contains an XML file package.xml that lists all the classes, triggers, and other objects to be deployed.
  • The root directory optionally contains an XML file destructiveChanges.xml that lists all the classes, triggers, and other objects to be deleted from your organization.
checkOnly
Specifies whether the classes and triggers are deployed to the target environment or not. This property takes a Boolean value: true if you do not want to save the classes and triggers to the organization, false otherwise. If you do not specify a value, the default is false.
runTests
The name of the class that contains the unit tests that you want to run.

This parameter is ignored when deploying to a Salesforce production organization. Every unit test in your organization namespace is executed.

Note

runAllTests
This property takes a Boolean value: true if you want run all tests in your organization, false if you do not. You should not specify a value for runTests if you specify true for runAllTests.

This parameter is ignored when deploying to a Salesforce production organization. Every unit test in your organization namespace is executed.

Note