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:
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:
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:
TestClass1
TestClass2
TestClass3
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.
