Various Deployment Tools available in salesforce
The Force.com Migration Tool is a command-line tool and migrates data between two environments, including Developer Editions orgs. Using Force.com migration tool, we can move data between two sandboxes and between sandbox and production.
The Force.com Migration Tool is a Java/Ant-based command-line utility for moving metadata between a local directory and a Salesforce org. Use the Force.com Migration Tool to perform repetitive deployments that can be scripted and that use the same components (the same package.xml file).
It uses project manifies calls package.xml. The manifest is an XML file that defines the components you’re migrating and specifies the version of the Metadata API to use.
Deleting Files from an Organization
destructiveChanges.xml. file
<?xml version="1.0" encoding="UTF-8"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
<types>
<members>MyCustomObject__c</members>
<name>CustomObject</name>
</types>
</Package>
To deploy the destructive changes, you must also have a package.xml file that lists no components to deploy, includes the API version, and is in the same directory as destructiveChanges.xml:
package.xml file
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
<types>
<members>*</members>
<name>CustomObject</name>
</types>
<version>39.0</version>
</Package>
Adding and Deleting Components in a Single Deployment
The only difference is that package.xml contains components which need to be added/updated.
By default, deletions are processed before component additions. In API version 33.0 and later, you can specify components to be deleted before and after component additions. The process is the same as with performing a delete-only deployment except that the name of the deletion manifest file is different.
- To delete components before adding or updating other components, create a manifest file that’s named destructiveChangesPre.xml and include the components to delete.
- To delete components after adding or updating other components, create a manifest file that’s named destructiveChangesPost.xml and include the components to delete.
<types>
<members>SampleClass</members>
<name>ApexClass</name>
</types>
<version>39.0</version>
</Package>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
<members>MyCustomObject__c</members>
<name>CustomObject</name>
</types>
</Package>
Deployment Tools
Change Sets and the Force.com Migration Tool are the recommended tools for migration. Change Sets is accessible through the Salesforce user interface and allows migrations between sandbox and production. T
The main use case of packages is for ISV developers to distribute apps to subscribers. But they can be used also for moving changes between Developer Edition orgs.
Delete Components
Specify components which needs to be deleted in destructiveChanges.xml and components to be added/updated in package.xml. This process is similar as process which only deletes components.
The ability to specify when deletions are processed is useful when you’re deleting components with dependencies. For example, if a custom object is referenced in an Apex class, you can’t delete it unless you modify the Apex class first to remove the dependency on the custom object. In this example, you can perform a single deployment that updates the Apex class to clear the dependency and then deletes the custom object by using destructiveChangesPost.xml. The following are samples of the package.xml and destructiveChangesPost.xml manifests that would be used in this example.
Package.xml file which contains class which needs to update
<?xml version="1.0" encoding="UTF-8"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
<types>
<members>SampleClass</members>
<name>ApexClass</name>
</types>
<version>39.0</version>
</Package>
destructiveChangesPost.xml, which specifies the custom object to delete after the class update:
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
<types>
<members>SampleClass</members>
<name>ApexClass</name>
</types>
<version>39.0</version>
</Package>
destructiveChangesPost.xml, which specifies the custom object to delete after the class update:
<?xml version="1.0" encoding="UTF-8"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
<types>
<members>MyCustomObject__c</members>
<name>CustomObject</name>
</types>
</Package>
Limit of deployment file size
- If using the Force.com Migration Tool to deploy an unzipped folder, all files in the folder are compressed first. The maximum size of uncompressed components in an unzipped folder is 400 MB or less depending on the compression ratio. If the files have a high compression ratio, you can migrate a total of approximately 400 MB because the compressed size would be under 39 MB. However, if the components can't be compressed much, like binary static resources, you can migrate less than 400 MB.
Different Types of Packages
