Below is an example. We will first retrieve the components from source org and then will deploy those components to the target org. Here is the folder that we have initially. We have build.xml and build.properties file here and one folder named “unpackaged” in which we have our package.xml.

This package.xml file contains the list of components to be retrieved from source org.

Build.properties : We provide the information about our instance on which we want to perform the operation (deploy or retrieve or any other possible operation). Below is the sample. Here in this file we have only enabled the username and password for source org as we will first retrieve the components from source org and build.xml file will use these credentials. But while deploying those components to target org , we’ll have to changes these credentials info to target org’s credentials, so that in the next target that we run from command prompt to deploy the components, the build.xml file will use the target org’s credentials for deployment of components.This is the file that is referred in the next file which is build.xml. All the lines in the below code that starts with # are considered as comments.

Build.xml : Here we provide the actions or we can say the operation that we want to perform ( either retrieve or deploy or any other possible operation). These tags are called targets also. So, user can run these targets one by one and complete the task in sequential manner as he/she wants. In the below example we have one retrieve target and one deploy target. Every target has some name which we’ll use when calling these targets from command prompt. This file refers build.properties file where we have mentioned all the info required in this file(like username, password, serverurl)

    <!– Setting default value for username, password and session id properties to empty string
         so unset values are treated as empty. Without this, ant expressions such as ${sf.username}
         will be treated literally.
    –>
    <condition property=”sf.username” value=””> <not> <isset property=”sf.username”/> </not> </condition>
    <condition property=”sf.password” value=””> <not> <isset property=”sf.password”/> </not> </condition>
    <condition property=”sf.sessionId” value=””> <not> <isset property=”sf.sessionId”/> </not> </condition>

    <taskdef resource=”com/salesforce/antlib.xml” uri=”antlib:com.salesforce”>
        <classpath>
            <pathelement location=”../ant-salesforce.jar” />           
        </classpath>
    </taskdef>

    <!– Shows deploying code & running tests for code in directory –>
    <target name=”deployCode”>
      <!– Upload the contents of the “codepkg” directory, running the tests for just 1 class –>
      <sf:deploy username=”${sf.myDevusername}” password=”${sf.myDevpassword}” sessionId=”${sf.sessionId}” serverurl=”${sf.serverurl}” maxPoll=”${sf.maxPoll}” deployRoot=”codepkg”>
       </sf:deploy>
    </target>

Package.xml : This is the last xml file that we need. We have to mention the API name of components that we want to retrieve from source org. And the same xml can be used while deploying those components to target org.

<?xml version=”1.0″ encoding=”UTF-8″?>
<Package xmlns=”http://soap.sforce.com/2006/04/metadata”>
    <types>
        <members>*</members>
        <name>ApexClass</name>
    </types>
    <types>
        <members>*</members>
        <name>ApexTrigger</name>
    </types>
    <version>41.0</version>
</Package>

This is continued in next post

Force.com migration tool(based on JAVA), is used to deploy the Metadata from one organization to other organization or we can use it to retrieve the metadata from one organization and then make some changes locally and then deploy that metadata again to the same organization.

Advantages of ANT over Changesets

• The main advantage of this tool is, that it gets the metadata in form of XML files from your server and downloads it locally on your computer. Thus you can make changes in those XML files locally and again deploy the changes to any server instance, any target org that you want.
• It allows you to deploy the same metadata any number of times to any of your server, as you have downloaded the metadata in form of XML files, you can deploy them again and again.
• Change set does not allow you to delete any metadata component from target org. But using ANT migration tool you can delete the components from target org. This is done using destructiveChanges.xml file.
• Some components are not supported to be migrated using change sets but you can migrate them using ANT migration tool.
• It can also be run from command prompt using some specific commands for calling APIs.
• You can also automate your migration process leveraging the capabilities of command prompt .bat files and XML structure of source files.

This tool works with the help of some XML files. In those XML files, we provide information about our server ( like credentials, login URL, and some other attributes as well, file is build.properties ) , information about the operation that we want to perform (these are called targets, like retrieve or deploy, file is
build.xml), then information about the components that you want to retrieve or deploy(package.xml).

This is continued in next post