Salesforce – Deployment Tools, Best Practices & Faster Deployment

When you are ready to deploy your changes to Production, a developer can use various tools to move metadata from one organization to another:

Change Sets:

The most frequently used tool for deployment when you want to send customizations from your Sandbox to Production org. This requires a deployment connection to be established between Sandbox and Production org. Change sets are the simplest way of doing deployments which uses point and click tool to migrate metadata instead of using xml files or scripts. It works between Sandbox and Production only.

Please follow the below doc to setup and use Change Sets:

https://help.salesforce.com/articleView?id=code_tools_changesets.htm&type=0&language=en_US&release=206.13

Force.com Migration Tool

The Force.com Migration Tool is most preferred tool a Java/Ant-based command-line utility for moving metadata between a local directory and a Salesforce org. There is no deployment connection required which means you can deploy the components from one org to any Salesforce org.

Please follow the below doc to setup and use Force.com Migration tool:

https://developer.salesforce.com/docs/atlas.en-us.daas.meta/daas/meta_development.htm

Force.com IDE / Eclipse

The Force.com IDE is a plugin for Eclipse which is very powerful tool for creating , modifying and deploying  the apex code. This tool can synchronize changes between any Salesforce Orgs. The main feature of Eclipse is that you can easily delete classes from Production org by changing the related metadata .xml file.

Please follow the below doc to setup and use Force.com Migration tool:

https://developer.salesforce.com/page/Force.com_IDE

Which tool we should use for Deployment?

Please follow the below chart below to decide which tool you may use for deployment.

Environment What we can do ? Developer Console Workbench Eclipse ANT
Production Create/Modify Code
Delete Code
Rename Class
Run/Debug Code

Run SOQL query
Deploy Code

No

No

No

Yes

Yes

No

No

No

No

Yes

Yes

Yes

Yes

Yes

Yes

Yes

No

Yes

Yes

Yes

Yes

No

No

Yes
Sandbox Create/Modify Code
Delete Code
Rename Class
Run/Debug Code

Run SOQL query
Deploy Code

Yes

Yes

Yes

Yes

Yes

No

No

No

No

Yes

Yes

Yes

Yes

Yes

Yes

Yes

No

Yes

Yes

Yes

Yes

No

No

Yes

Plese check out the link below for more information:

https://help.salesforce.com/articleView?id=code_tools_ant.htm&type=0&language=en_US&release=206.13

What are the Best Practices to make your deployment faster?

Whenever we push any apex class or triggers to Production all of the apex tests are run as part of the deployment process. If there are lots of test classes and customization it can take a really long time to run the tests which will increase the time taken for Deployment.

We can always reduce the deployment time by following best practices :

Always Use (SeeAllData=false)
When you annotate your test class or test method with (SeeAllData=true) it opens up data access to records in your organization. This value should not be set to true because we don’t want our test methods to trust on existing data which may cause your test classes failed to run if there is no existing data found for particular scenario.

We should always create independent test data with seeAllData=False and it also avoids any SOQL to extract the existing data from org.

Apex Classes created after version 23 are automatically using SeeAllData = false unless the class or methods are marked explicitly with SeeAllData = true. We can still query Users, Profiles, User Groups etc. even if SeeAllData=false. However there are some objects that cannot be queried with SeeAllData = false e.g Standard Pricebook..

Please check the link below for more information:

https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_testing_seealldata_using.htm

 

Run a Subset of Tests

Test levels enable you to have more control over which tests are run in a deployment. To shorten deployment time to production, run a subset of tests when deploying Apex components.

  • While deploying the change set, we can run specific test by choosing the option “Run Specific Tests” and defining the name of the relevant test classes.
  • While deploying using ANT migration tool, we can define which test should run:
<target name="deployCode">
    <sf:deploy username="${sf.username}" password="${sf.password}" 
           sessionId="${sf.sessionId}" serverurl="${sf.serverurl}"
           deployroot="codepkg" testLevel="RunSpecifiedTests">
        <runTest>TestClass1</runTest>
        <runTest>TestClass2</runTest>
        <runTest>TestClass3</runTest>
    </sf:deploy>
</target>

Use @testSetup

You should use @testSetup at the top of your test class and this is very useful which can be time-saving when you need to create a common set of records that all test methods operate on or prerequisite data. Each test methods receives a fresh copy of test data created using @testSetup method.

In below example: we are creating an Account using @testSetup method, this record can be accessible in all test methods. :

@testSetup static void methodName() {
 Account acc = new Account();
 acc.Name = 'Test Account';
 insert acc;
}

For more information about @testSetup:

https://developer.salesforce.com/releases/release/Spring15/TestClasses

Use System.Assert()
In order to check whether the test data is really useful and returning the results as expected and contributing to code coverage, you must use System.Assert() method.  This is always useful to remove any test data which doesn’t contribute to code coverage.

In the below example, the expected name of the Account is ‘Test’. If we give the name other than ‘Test’, it will throw error.

public class SampleClass {
    public void insertAcct(String name, String extId) {
        Account acc = new Account(Name = name,External_ID__c = extId);
        insert acc;
        System.assertEquals('Test',acc.Name);
    }
}

For more information about system.Assert():

https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_testing_example.htm

Avoid using System.RunAs  
System.RunAs will take more time to execute than without. You will need to use System.RunAs as wisely to reduce execution time for running the test class. If your organization has more than a thousand test methods System.RunAs will start to add up and will make your deployment slow.

 

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s