Debug and Development Tools consists of 5% of total score in Salesforce Platform Dev II Exam. The topic covers including performance profiling and troubleshooting, and Salesforce deployment tools such as change sets, Force.com Migration Tool, Force.com IDE (retiring), Workbench, Force.com CLI and etc.

NOTE: This post is written in July 2019 and content might be changed/updated overtime. The content is inspired by focusonforce.com

Performance Profiling

  • Performance profiling refers to the process of identifying potential performance issues, applying best practices to fix bottlenecks and improve perfomance , making sure that the application are fast and scalable.
  • Steps of performance profiling:
    • Define scope of profiling to split scenarios into different functionalities
    • Analyze and measure performance of application for each functionality
    • Identify potential bottleneck and root cause, then fix them up
    • Compare results and repeat previous steps until all the bottlenecks are removed
  • Tools for performance analysis and troubleshooting:
    • Web analysis tools, such as Chrome Developer Tools
    • Debug traces set up for users and Apex Class
    • Debug mode can be enabled in Setup > Debug Mode by selecting the user who needs to have debug mode on
      • When Debug mode is on, the framework Javascript code is not minified, but the tradeoff is that page will load slower because of loading larger file resource
      • NOTE: default execution code is production, which means the framework code is optimized, minified, and obfuscated to reduce the size of the code (custom component code is not minified or obfuscated), hence optimizing the performance.
      • User who has Debug mode on will see a banner notification once a week.
      • Google Chrome extension Salesforce Lightning Inspector can be used to inspect code easily.
    • Analyze Debug Log
    • Workbench can come in handy to analyze the query
  • When profiling performance of a SOQL query, it is a good practice to include all deleted and archived records in the Workbench. The selectivity of a query should be assessed by combining the filters for AND operators. For OR operators, each filter’s selectivity must be assessed separately. It is also recommended to ensure that the selective fields are indexed.
  • NOTE: multiple short bursts of Apex events in Execution Overview Timeline usually indicates inefficient loop logic.

Development Tools

Change Sets

  • Change sets can be used to deploy metadata between related sandbox/production org without a local file system.
  • NOTE: it cannot be used to delete or rename components and not suitable to use with source control.
  • Suitable for small deployments.

Force.com Migration Tool

  • Force.com Migration Tool is a Java/Ant-based CLI for moving metadata betweena local directory and a Salesforce org.
  • Suitable for big deployments with lots of setup changes, multi-stage release processes, repetitive deployments, and scheduling batch deployments.
  • NOTE: it requires username and password to be stored on local file system.

Force.com IDE (retiring October 2019)

  • Force.com IDE is an Eclipse plugin that is used for both development and deployment.
  • It can deploy to any org.
  • It is not suitable for repetitive deployment as components need to be reselected every time.

Force.com CLI

  • Force.com CLI is the CLI for Force.com API that allows exporting and importing metadata.
  • It allows deployment using scripted commands and automated tasks.
  • The only difference between Force.com Migration Tool is that it doesn't require to store username/password in the file system as it forces user to login to the target org.
  • NOTE: logging in behind firewall can be challenging.

Workbench (unofficial)

  • Force.com Workbench is a lightweight web-based tool that can be used to deploy or retrieve components using package.xml.
  • It uses local file system.
  • Project manifest file lists what to retrieve or deploy. The <types> element in the file contains the metadata type and the named members to be retrieved or deployed.
  • The metadata type is defined using <name>, and individual components of a particular metadata type are defined using <members>. Also, all components of a metadata type are retrieved using the *(asterisk) wildcard character.
  • Example of package.xml:
<package xmlns="http://soap.sforce.com/2006/04/metadata">
    <!-- specify standard Account object as member of CustomObject -->
    <types>
        <members>Account</members>
        <name>CustomObject</name>
    </types>

    <!-- asterisk * cannot be used with all standard objects -->
    <types>
        <members>Account</members>
        <name>CustomObject</name>
    </types>    
    
     <!-- represent Industry standard picklist as StandardValueSet type -->
    <types>
        <members>Industry</members>
        <name>StandardValueSet</name>
    </types>      
    
     <!-- set corresponding Industry standard value to Account -->
    <types>
        <members>Account.Industry</members>
        <name>CustomField</name>
    </types>      
 
    <!-- custom field in custom object -->
    <types>
        <members>MyCustomObject__c.MyCustomField__c</members>
        <name>CustomField</name>
    </types>      
    
    <!-- standard/custom field in standard object -->
    <types>
        <members>Account.SLA__c</members>
        <members>Account.Phone</members>
        <name>CustomField</name>
    </types>       

    <!-- list view for standard objects -->
    <types>
        <members>Account.AccountTeam</members>
        <name>ListView</name>
    </types>       
    
    <!-- security settings -->
    <types>
        <members>Security</members>
        <name>Settings</name>
    </types>        
    
     <!-- assignment rules for Case and Lead -->
    <types>
        <members>Case</members>
        <members>Lead</members>
        <name>AssignmentRules</name>
    </types>   
    
    <!-- access specific assignment rule for Case and Lead -->
    <types>
        <members>Case.samplerule</members>
        <members>Lead.samplelead</members>
        <name>AssignmentRule</name>
    </types>     
           
    <types>
        <members>*</members>
        <name>AnalyticSnapshot</name>
    </types>
    
    <types>
        <members>*</members>
        <name>ApexClass</name>
    </types>
    
    <types>
        <members>*</members>
        <name>ApexComponent</name>
    </types>
    
    <types>
        <members>*</members>
        <name>ApexPage</name>
    </types>    
    
    <types>
        <members>*</members>
        <name>ApexTrigger</name>
    </types>    
    
    <types>
        <members>*</members>
        <name>Auth</name>
    </types>    
    
    <types>
        <members>Standard</members>
        <name>Profile</name>
    </types>    

    <types>
        <members>*</members>
        <name>Role</name>
    </types>    
    
    <types>
        <members>*</members>
        <name>PermissionSet</name>
    </types>        
    
    <types>
        <members>*</members>
        <name>CustomTab</name>
    </types>    
    
    <types>
        <members>*</members>
        <name>Flow</name>
    </types>    
    
    <types>
        <members>*</members>
        <name>AnalyticSnapshot</name>
    </types>
    
    <version>46.0</version>
</package>

Well, that's it! Pretty short chapter and this will be the final chapter of Platform Developer II Exam! Have a wonderful time, mi amigo! See you all next time!

Post was published on , last updated on .

Like the content? Support the author by paypal.me!