Migration tool to deploy metadata

 Migration tool to deploy meta data between Organizations

Migration tool is used to deploy the Metadata from one organization to other organization. By using this tool first we will get the code to our local from source organization and we will deploy from local to target instance. It is very easy process to deploy the large number of components from source to target instance.

Force.com migration tool is a java/Ant based command line utility for moving the Meta data between local directory and a Salesforce organization. The Force.com Migration Tool is especially useful in the following scenarios:

1. Development projects where you need to populate a test environment with large amounts of setup changes — making these changes using a Web interface could take a long time.

2. Multistage release processes — a typical development process requires iterative building, testing, and staging before releasing to a production environment. Scripted retrieval and deployment of components can make this process much more efficient.

3. Repetitive deployment using the same parameters — you can retrieve all the metadata in your organization, make changes, and deploy a subset of components. If you need to repeat this process, it’s as simple as calling the same deployment target again.

4. When migrating from stage to production is done by IT — anyone that prefers deploying in a scripting environment will find the Force.com Migration Tool a familiar process.

Installing Force.com migration tool

1. Install Java on your local machine

Go to http://www.oracle.com/technetwork/java/javase/downloads/index.html. And get the latest version of the Java JDK and install it on your machine.

2. Install ANT in your local machine.

Go to http://ant.apache.org/bindownload.cgi and get these files to your local. Once these files are on your computer, there is no further installation required.

3. After installation of java and ANT, create following environment variable to set the path.

Variable Name Path
ANT_HOME Here give Ant location on your machine. For example in my machine I have stored ant in “C:\Ant\apache-ant-1.8.4” location
Path C:\Program Files\Java\jdk1.6.0\bin;%ANT_HOME%\bin

If you are working under proxy network you need to create one more additional environmental variable to specify proxy settings.

 4. Download Salesforce.jar file and add that file to your ant installation’s lib directory.

To download this Go to setup->Develop-> click on Tools -> and click on Force.com migration tool to download this. Refer following screen.

Migration tool

After downloading extract the downloaded ZIP file and copy the ant-salesforce.jar file and paste it in Ant lib directory in your ant installation file.

5. Now Force.com migration tool installation is completed.

To verify java installation open command prompt ant type “Java –version” you will get the following message based on the java version. 

java version “1.6.0_37”

Java(TM) SE Runtime Environment (build 1.6.0_37-b06)

Java HotSpot(TM) Client VM (build 20.12-b01, mixed mode, sharing)

To verify ANT installation type ant –version in command prompt, you will get following message based on the ANT version.

Apache Ant(TM) version 1.9.1 compiled on May 15 2013

How to use Migration tool to deploy components in Salesforce?

To deploy metadata by using this migration tool we need prepare below mentioned three important files.

1. Build.properties file: This file contains your organization’s credentials in order to run the tasks in build.xml file.

Parameters used in build.properties file

Parameter Value
username Here you need to mention your organization user name like below users.For example testuser@tut.com  in production, testuser@tut.com.devbox in sandboxThis users must have “modify all data” permission to deploy components.
password You have to specify your password along with security token(Password + Security token)
serverurl For production it is https://login.salesforce.comFor sandbox it is https://test.salesforce.com 

 2. Build.xml file: This file specifies a series of commands to be executed by Ant. Within the build.xml file are named targets that process a series of commands when you run Ant with a target name. below image describes sample build.xml


3. Package.xml: This file is a project manifest that lists all the components you want to retrieve or deploy in a single request. You can retrieve or deploy only a single package at a time. Below image describes sample package.xml file

migration tool - Package.xml

You can get these sample(build.xml and build.properties) files from migration tool zip file downloaded earlier as part of installation.

After creating these three files Place these files in a folder, place package.xml file in separate folder inside this folder, see the following image for reference.

Migration tool

Place the package.xml file in codepkg folder.

Once you have done with this setup, you can run this script in Command prompt.

How to run this script in command prompt

1. Open command prompt and enter file path of your build.xml file.

For example I have placed my build.xml file in “C:\Build”. Enter this command in command prompt “cd C:\Build”.

2. Now retrieve the code your local from source organization. To retrieve the components mentioned in your package.xml run the command “ant retrieveCode” which is mentioned in your build.xml

3. Once you have done with retrieving components to your local, now you can deploy those components to your target organization. To deploy your components run the command “ant deployCode”, which is mentioned in your build.xml file.

If your deployment is success, you will get successful message. In case of failure you will get the list of errors.

How to run specified tests during Salesforce cloud deployment

Quick deployment in Salesforce

Deployments by using change sets

Deployments by using change sets

By using change sets we can deploy our customizations from one environment to other environments in Salesforce.

Change sets available in Enterprise, performance, unlimited and Database.com editions.

Note: In this post organization/environment means it may be sandbox or production. By using change sets we can deploy code from sandbox to sandbox and also we can deploy Sandbox to production.

Prerequisites to deploy by using change sets

1. A deployment connection between two organizations.

2. Overall test class code coverage should be greater than 75%.

3. Create and upload change sets user permission to create or upload change sets.

How to do deployments by using change sets?

1. Create outbound change set in source organization and upload that change set to Target instance.

2. In target instance go to inbound change set and go to the change set uploaded from source instance and deploy that change set.

For example you have done with your customizations in Developer sandbox. You are trying to deploy your changes from Development environment to TEST/PRODUCTION. In this case first create connection between DEVELPOPMENT Sandbox to TEST/PRODUCTION

 Once connection is established go to outbound change set and create one outbound change set in DEVELOPMENT sandbox and add list of components to that outbound change set. Next upload that change set to TEST/PRODUCTION. Next in your target instance go to inbound change set in TEST/PRODUCTION and deploy that change set.

What is inbound change set and outbound change set?

Outbound change set: An out bound change set is a change set created in Source organization and that you want to deploy to target organization.

Sending an outbound change set to another organization doesn’t guarantee that the changes will be implemented in that organization. The change set must be deployed (accepted) by the target organization before the changes take effect.

Inbound change set: An inbound change set is change set that is sent from source organization to the target organization. A change sent must be deployed for the changes to take effect. You can deploy the contents of an inbound change set as a whole, but not on a component-by-component basis.

To deploy your changes by using change set follow below steps

1. Set up -> Deploy -> click on “Outbound change sets”, you will navigate to following screen.

Change sets

Click on new button and provide required details name and description and click on save.

2. After saving you will navigate to following change set detail page. No you have to add your components to change set.

Change sets

Click on “add” button (which is marked in yellow color in above screen) to add components to your change set.

3. After adding all components to change set, click upload button to upload this change set to target organization. See the following image for reference.

Change Sets

Make sure that you have already established connection between source and target instance. If you are not established connection between source and target, follow the below steps to create connection.

Go to setup-> deployment connections -> select you target and click on edit -> and check the “Allow inbound change set” and click on save.

4. After uploading the change set go to your target organization and click on inbound change sets and click on the change set uploaded by you. See the below image for reference.

Change Sets

5. Next click on Deploy button to deploy your changes.

If you aren’t ready to deploy at this time, you can click Validate to preview deployment results without committing any changes. It isn’t necessary to validate before deploying, as the deployment won’t commit any changes if there are failures.

Change Sets

6. After the deployment you can see the status value with Deployed. And you can view the results. See the below image for reference.

Change Sets

If there are any failures you will get Status with Failure value and you can see error messages in View Results.

Note: By using change sets you can deploy 2500 components at a time.

Sandbox Limitations

Sandbox Limitations

1. Following table describes Sandbox Storage limits

Sandbox Type Storage Limit
Developer Sandbox 200 MB
Developer Pro Sandbox 1 GB
Partial Data Sandbox 5 GB and maximum 10,000 record per selected object.
Full Copy Same Storage limits as your production organization.

To know about storage usage in your organization follow below steps.

Setup -> data management -> click on storage usage.

2. Sandbox refreshing limits

Sandbox Type You can refresh
Developer Sandbox Once per day
Developer Pro Sandbox Once per day
Partial Data Sandbox You can refresh a Partial Data sandbox 5 days after you created or last refreshed it. If you delete a Partial Data sandbox within those 5 days, you need to wait until after the 5 day period, from the date of last refresh or creation, to replace it.
Full copy Sandbox You can refresh a Full sandbox 29 days after you created or last refreshed it. If you delete a Full sandbox within those 29 days, you need to wait until after the 29 day period, from the date of last refresh or creation, to replace it.

Creating Sandbox in Salesforce

Creating Sandbox

To create sandbox following permissions are required.

To view a sandbox: View setup and configuration.

To create, refresh, activate and delete sandbox: Modify all data

To create sandbox follow below steps.

1. Go to setup -> Deploy -> click on Sandboxes, then you will navigate to following screen

Sandbox - Creating sandbox

2. Click on “new sandbox” button then you will navigate to following screen. Enter required data like sandbox name.

Creating Sandbox

3. Select the type of the sandbox you want to create and then click on next (here I am creating full copy sandbox which is marked in above screen). You will navigate to following screen by clicking on next button for full copy sandbox.

Creating Sandbox

Here select the object data bases on your requirement like all or Template based. And also select include object history data/Include chatter data based on your requirement.

4. And click on “Create” button then you will navigate to following screen.

Creating Sandbox

In the above screen it is showing status “pending” and also Copied on date is empty. After completion of the sandbox creation Copied date will come. Generally this sandbox creation time depends on metadata and data of your organization.

Creating Sandbox

Refreshing a Sandbox

You can refresh you sandboxes based on the type of sandbox. You can refresh developer and developer Pro boxes once per a day. And you can refresh Partial data box every five days. You can refresh Full copy sandbox every 29 days.

To refresh sandbox follow the below step

1. Click on sandboxes under setup menu then you will navigate to following screen.

Refreshing a sandbox

2. Next to the sandbox name click on Refresh button.

3. Select the data you want to copy

       For a Full sandbox, choose how much object history, case history, and opportunity history to copy, and whether or not to copy Chatter data. Object history is the field history tracking of custom and most standard objects; case history and opportunity history serve the same purpose for cases and opportunities. You can copy from 0 to 180 days of history, in 30–day increments. The default value is 0 days. Chatter data includes feeds, messages, and discovery topics. Decreasing the amount of data you copy can significantly speed up sandbox copy time.

4. Click Refresh button

 Salesforce starts copying data to the sandbox.

After Salesforce finishes copying data to the sandbox, you still need to activate the sandbox before you can use the refreshed data. Salesforce sends you an email when your sandbox is ready to activate.

Sandboxes in Salesforce

Introduction to Sandboxes

Sandbox is a copy of your production organization. You can create multiple copies of your organization in separate environments for different purposes such as development, testing and training, without compromising the data and applications in your production organization.

Sandboxes are completely isolated from your Salesforce production organization, so operations you perform in your sandboxes do not affect your Salesforce production organization, and vice versa.

Generally in each phase of project requires different environments like during construction phase there are chances to multiple teams will work on development in this case each team requires their own sandboxes for development. After the construction period we need one common testing environment, during training period training team requires  separate environment for training purpose and before going to production one STAGING environment required. So for each phase different environments are required.

To understand this see the following SDLC diagram.



Development Life Cycle

1. Create development environments.

2. Develop using Salesforce Web and local tools.

3. Create testing environments, including UAT and integration.

4. Migrate changes from development environment to integration environment.

5. Test.

6. Migrate changes from integration environment to UAT environment.

7. Perform user-acceptance tests.

8. Migrate changes from UAT environment to staging environment.

9. Replicate production changes in staging environment.

10. Schedule the release.

Types of Sandboxes

Salesforce now providing four types of sandboxes.

1. Developer Sandbox

2. Developer Pro Sandbox

3. Partial Data Sandbox

4. Full Sandbox

Developer Sandbox

Developer sandbox is a copy of production, it copies all application and configuration information to the sandbox. This type of sandboxes limited to 200MB of test or sample data, which is enough for many development and testing tasks. You can refresh a developer sandbox once per day.

Developer Pro Sandbox

Developer Pro sandboxes copy all of your production organization’s reports, dashboards, price books, products, apps, and customizations under Setup, but exclude all of your organization’s standard and custom object records, documents, and attachments. This type of sandboxes limited to 1GB of test or sample data. We can refresh developer pro type sandboxes once per day.

Partial Data Sandbox

A Partial Data sandbox is a Developer sandbox plus the data you define in a sandbox template. It includes the reports, dashboards, price books, products, apps, and customizations under Setup (including all of your metadata). Additionally, as defined by your sandbox template, Partial Data sandboxes can include your organization’s standard and custom object records, documents, and attachments up to 5 GB of data and a maximum of 10,000 records per selected object. A Partial Data sandbox is smaller than a Full sandbox and has a shorter refresh interval. You can refresh a Partial Data sandbox every 5 days.

Sandbox templates allow you to pick specific objects and data to copy to your sandbox, so you can control the size and content of each sandbox. Sandbox templates are only available for Partial Data or Full sandboxes.

Full Copy Sandbox

Full copy sandboxes are exact copy of production including standard and custom objects records, attachments and documents. You can refresh full copy sandbox every 29 days.