Salesforce Ant Migration
Sep20

Salesforce Ant Migration

Ant Migration tool is used to Create and Fetch Metadata to and from an organisation.  It’s a  command-line utility by which one can upload and download Metadata components. Benefits Its very useful for creating repetitive deployment or may be a large number of components just by executing a command in an command line interface. Useful for uploading test environment with a lot of configuration settings. Manually creating Fields, Objects may take a huge amount of time when you create them by clicking with the salesforce interface. These fields can be created with one command in the Command line interface and using Package.xml file in which you specify the information about all the fields. The Name of the components we can Deploy or retrieve are as follows: Custom Fields. Objects. Workflow rules. Apex Triggers. Apex Class. Visualforce Pages. Etc. The Whole list is mentioned in this link: https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_types_list.htm   Installation Download Force.com migration tool from your salesforce organisation. Go to Setup. Type “Tool” and Click on Force.com Migration tool & Toolkits. Go to the Following Link for downloading Ant: https://gs0.salesforce.com/dwnld/SfdcAnt/salesforce_ant_36.0.zip Add the bin directory to your path. Set the ANT_HOME environment variable to the directory where you installed Ant. Set the JAVA_HOME environment variable to the directory where the JDK is installed. Run command in Command line Interface:   “ant -version” to check the version and confirm the installation. Usage Create three Files: Package.xml – Which consists the specifications for the components. Package.xml <?xml version=”1.0″ encoding=”UTF-8″?> <Package xmlns=”http://soap.sforce.com/2006/04/metadata”>    <types>        <members>*</members>        <name>CustomObject</name>    </types>    <version>37.0</version> </Package> Build.properties – Which consists the Credentials of the salesforce Organisation to & from which you want to Upload/Download. Build.properties sf.usernameDownload = Sf.User@Name.com sf.passwordDownload = Password122   sf.usernameUpload = Sf.User@Name.com sf.passwordUpload = aasfde@12131QV4cWJnmdflgBRdXsWznzohG sf.serverurlDownload = https://login.salesforce.com sf.serverurlUpload = https://login.salesforce.com sf.maxPoll = 100 Note: You have to mention Security token at the end of the password of the Org in which you want to Upload the metadata.   Build.xml – This file is used to set the attributes which will be used in the Command line interface such as “Project Name”,”Property File”,”retrieveTarget folder( where Downloaded metadata info will be saved)”,”unpackaged(Package.xml file)”. Build.xml <project name=”ANT Migration” default=”test” basedir=”.” xmlns:sf=”antlib:com.salesforce”>   <property file=”build.properties” /> <property environment=”env” /> <target name=”retrieve”> <mkdir dir=”Retrieve” /> <sf:retrieve username=”${sf.usernameDownload}” password=”${sf.passwordDownload}” serverurl=”${sf.serverurlDownload}” retrieveTarget=”Retrieve” unpackaged=”unpackaged/package.xml” pollWaitMillis=”10000″ maxPoll=”100″ /> </target> <target name=”upload”> <sf:deploy purgeOnDelete=”true” username=”${sf.usernameUpload}” password=”${sf.passwordUpload}” serverurl=”${sf.serverurlUpload}” deployroot=”Retrieve” pollWaitMillis=”10000″ maxPoll=”100″ /> </target> </project> Go to the path where you stored these files and then Run commands as follows: Upload(Which you mentioned in your build.xml file as target) – For uploading components you mentioned in the Package.xml file. Retrieve– For downloading the Components information you mentioned in the package.xml file...

Read More
Salesforce Code Move Strategy
Aug09

Salesforce Code Move Strategy

Why sometimes a few lines of code changes take several days of deployment. Find the answers and Code Move Strategy:- Recently In one of my project I faced the following situation: We did a code change in trigger. Changed a string value from “Demo” to “Trial”. The code change hardy took 1 minutes. Client was aware of the changes and  time it will take so we estimated the work as 2 hour including code changes, analysis of its impact and deployment. When the developer finished deploying the code changes it took him 2 days (16+ Man-hours). Yes it is a surprise. Now let me list out the problems he faced.   Code coverage of the existing trigger was 12% (Our Company Best Practice is 85%) Code coverage of overall production org was less than 75%. Yes this is hard to believe but this do happen when we push things in production without code coverage. Existing test classes were failing in production. Trigger in production was different than in Sandbox. Yes this is also possible when we have multiple sandboxes and people do code overrides as they are competing against each others. Deployment had a narrow slot of 2 hours during which end client were not working. Batch Jobs working on the same object were preventing the Trigger to deploy. We gave our best as a team and came up with the following strategy which changed our entire company’s estimation and requirement analysis process. Code Move Strategy: Step 1: Check the existing production code coverage by “Run All Test”. Step 2: Lookout for test class failures if any. Step 3: List out the Batch jobs running in production. Step 4: Compare the code between production and sandbox before working on it. If any differences found report it to your end Client/Manager. Step 5: Make sure if you are deploying an apex code its code coverage should be above 85%. Step 6: Use Changeset for small size deployment with less components. Keep the changeset names in a well defined order. Step 7: Use Eclipse or Ant Migration tool for deployment with many components.If you have the privilege of Full copy sandbox use it for trial deployment and go live. Full copy sandbox gives you an advantage of less risk more effort based deployment process. Step 8: Deactivate the necessary batch jobs and validation rules before deployment. Step 9: Make sure the deployment is in the right time slot when end users are not working or keep the team informed for any surprises that may come while deployment or after that. Step 10: Validate and Deploy. Reactivate the Jobs, VRs etc. Step...

Read More