Your runAllTests request is using too many DB resources

A couple of months ago, I have encounter a very strange error when deploying components in Production where Salesforce is throwing an error message saying "Your runAllTests request is using too many DB resources". Digging deeper on the error message, I came upon this knowledge article that mentions of a limit 350,000 of DML rows on all test classes. What's fascinating is that the limit is not in the documentation. From what I understood, the limit is associated with the oracle database rollback used in the backend.

This is really a big issue specially if there are a lot of applications on your instance and you plan to add one. Also, regardless whether you optimise your code to limit data created on test classes, it would be a matter of time before you reach the limit. If your environment is not yet enabled for FAST deploy as discuss in my previous blog post, you will not be able to do regular deployment.

As of right now there is no fool-proof solution for this. However, there are a couple of things I would recommend you check in case you are getting the error message.

1. Check if your environment is loading bulk data from static resource. I'm not a big fan of the Salesforce documentation because some of the information are vague (at least for me) and having to clarify to support how salesforce computes, let's say a limit is so slow and takes weeks to confirm based on my experience. Basically loading data from static resource using Test.loadData are computed as part of this overall DML row limit.
2. Are you using Custom Settings as holder of your environment variables? One of the things I learned from previous Dreamforce sessions is that you can use custom settings as holder of environment variables so that you don't need to maintain static values on a class since its hard to redeploy components in Production environment and using custom labels to do this may not be the best solution (and using custom labels for storing such values are not good since it should be used for multi-lingual content). This is a similar pattern used for Java and even .NET that is handy. However you may want to review this pattern because it will be a liability at the end because of the limit.
3. Consider Multi-Org Setup. I'll be honest, as of right now I haven't implemented this on a client but having said that, having multiple instances definitely means you have separate limits for each of your unrelated applications. If for somehow some of your applications are connected then maybe you can take a look at Salesforce to Salesforce feature. 
4. Use SeeAllData=true. I don't really recommend this since it slows down processing of test classes and it is not a best practice but it can be a temporary workaround specially if you are loading a lot of test records from your test classes regardless if its coming for custom settings or coded in the class.
5. Check with if Managed Package will help. Now this is something I'm not sure will work and you may want to check with Salesforce but from what I understand, managed package has its own limits with unmanaged package. (I would appreciate if someone can confirm if it would work or not.)

I hope you find the list above helpful. Let me know if you encounter the same issue and if you have any thoughts on how to fix the issue. In addition, please vote my idea on removing DML row limit for loading data using static resource.

Install Android Lollipop OTA manually on a MAC

After days of frustrations for getting the OTA update on Android lollipop, I decided to manually install the firmware on my Nexus 5. Searching the internet I stumbled upon this Youtube video by an awesome guy on how to install the update which I try to list down the steps for newbies like me to follow.

This will NOT delete any files from your device! 
Follow the steps at your own risk!

PRE REQUISITE

• Android SDK
• Android Lollipop OTA file

STEPS TO FOLLOW

1. Extract the Android SDK on any location you want on your MAC. (I put it on my Documents folder).

2. Copy the OTA file under sdk/platform-tools folder of the extracted Android SDK location. Optionally rename the zip file to whatever you want (I renamed it as lollipop.zip as per the youtube below above).

3. Plug your Nexus 5 to your MAC.

4. Open Terminal and go to the location of the platform-tools folder by executing the below without quotes (Please note location change depending on where you extracted the SDK):

"cd Documents/android/sdk/platform-tools" 

5. Execute "./adb devices" to verify if your device connected.

NOTE

• If there is no device, make sure that your Nexus 5 is on debugging mode by going to go to Settings --> {} Developer options. If you cannot see this option, check this site. 
• If you need instruction on how to enable debugging mode see link. 

6. Go to recovery mode by pressing the power button and volume down or executing the below without quotes in Terminal:

"./adb reboot-bootloader"

7. Select "apply updates from ADB" option.

8. Execute the following in Terminal without quotes (replace the file name with the actual file name from step 2):

"./adb sideload lollipop.zip"

NOTE

• Do not disconnect your phone from your laptop.

9. Wait for till the phone completes the installation.

Congratulations you are now in Lollipop!

REVIEW: FAST Deploy using Force.com Ant Migration Toolkit

One of the pain points when deploying components in Salesforce regardless if you use ChangeSet, Force.com IDE or ANT is the fact that it runs all test classes in your Production environment if one of the components being deployed are one of the following metadata types (as per the metadata api document developer guide v31).

• ApexClass
• ApexComponent
• ApexPage
• ApexTrigger
• ArticleType
• BaseSharingRule
• CriteriaBasedSharingRule
• CustomDataType
• CustomField
• CustomObject
• DataCategoryGroup
• Flow
• InstalledPackage
• NamedFilter
• OwnerSharingRule
• PermissionSet
• Profile
• Queue
• RecordType
• RemoteSiteSetting
• Role
• SharingReason
• Territory
• Validation Rule
• Workflow

Now imagine if your environment contains a huge amount of customization. This would mean you might have hundreds to thousands of apex test classes that are being run every time you deploy. The time it takes to run all of these test classes depends on how optimized the codes and test classes were written and I have experienced waiting for 4 hours for a couple hundred of apex codes to be deployed to Production.

Introducing FAST Deploy (Pilot)

FAST Deploy allows admins to specify specific test classes to run during deployment and the current instance I'm supporting was fortunate enough to be a part of the program and I could say that it really provides good value specially to administrators. The duration of our deployments are now cut from hours to minutes. 

How to use FAST Deploy (Pilot)

The following are the prerequisites:

1. The instance should be a part of the pilot program (contact your account manager).
2. Currently this is only possible when using the ANT Migration Toolkit.

If you are familiar with ANT Migration scripting then it is fairly easy, otherwise you can learn more in this link. You just need to add a new <runTest> node on your <sf:deploy> from the build.xml of your ANT script. See example below:

<target name="deployCode">

<sf:deploy username="${sf.username}" 

password="${sf.password}" serverurl="${sf.serverurl}" 

maxPoll="${sf.maxPoll}" deployRoot="codepkg">

<runTest>TestClassName1</runTest>

<runTest>NameSpace.TestClassName2</runTest>
</sf:deploy>


</target>

Here's a screen shot of a sample deployment from Setup -> Deploy -> Deployment Status section. Most of the components here are apex codes and custom fields but the deployment only ran 12 test methods and took only 5 minutes.

There are a few caveats though on using the feature:

• The test classes specified to run must cover 75% code coverage for each apex triggers/classes in the package.xml.
• Aggregate code coverage from different test classes are not counted. For example, if 1 test class covers 50% of an apex trigger and another test class covers 25% for the same trigger, if both test classes are run, this is not considered as 75%.
• As mentioned above, all these are only possible using Force.com ANT migration toolkit.

As this only runs a subset of the test classes from the environment, I recommend administrators to ensure that all test classes are run from time to time to get the overall code coverage from the environment.

Salesforce Login Types

For some reason I could not find any public salesforce documentation or KB articles that discusses what each of the login types means in the Login History page. So I asked support to understand each and they provided me with the table below which I'm sharing to help anyone who may be needing it.

Login Type	Description
Application	UI login
Chatter Communities External User	Community User Login
Other Apex API	Other Apex API
Partner Product Partner	Integration Login
Remote Access 2.0	OAuth 2.0 login ( for example, connected app login)
SAML Chatter Communities  External User SSO	Community User Login from Single-Sign-On
SAML Idp Initiated SSO	SAML Single-Sign-On with login initiated  from Idp(Identity Provider) side
SAML Sfdc Initiated SSO	SAML Single-Sign-On with login initiated  from Salesforce side, redirect to Idp then  login after got Idp's SAML response
SYNC	Login from SYNC client

Unlocking the power of custom settings for data loading

Common use case when doing data load is to not to execute anything from the environment such as workflows, validation rules or apex triggers. This can only be achieve if (1) you have migrated only object you are targeting to do data load while workflow and triggers are not yet deployed or (2), workflows and triggers are inactivated which is somehow a hassle to admin or developers as they have to manually deactivate the workflow and worst deploy the inactivated triggers or (3), you explicitly includes user to skip on the workflow criteria or apex codes on triggers. Custom Settings can be used to hold configurations specific to user for skipping such automations.

Below is a sample custom settings I created with 3 fields.

I also created a small apex class that will interface with this custom settings and will be used on apex triggers.

public class AutoSkipSettings {
    
    public static boolean skipTrigger(){
        boolean skipTrigger = false; 
     
        Automation_Skip_Settings__c userSkipSetting = 
             Automation_Skip_Settings__c.getValues(UserInfo.getUserId());
        
        if(userSkipSetting <> null && userSkipSetting.Skip_Trigger__c){
            skipTrigger = true;
        }

        return skipTrigger;
    }
    
}

The apex triggers basically just extracts the custom setting value for the user and return the value of the checkbox. In this case, I'm returning the value of the Skip_Trigger__c field. Now we are ready to use the custom settings on validation and workflow rule criteria and apex trigger.

On the validation or workflow rule, the custom setting fields will be available as a global variable. Note that for workflow rule, you need to select 'formula evaluates to true' on the rule criteria section.

On any apex trigger, use the apex class created above.

trigger TestAccountTrigger on Account (before update) {
    
    if(!AutoSkipSettings.skipTrigger()){
    // do anything here
    }
    
}

Additional Notes:

• The reason why we used hierarchy type for custom setting is so that we can have a default organization level value. 
• The custom setting is much better than using custom object so that we save 1 SOQL query on the code and reference the field as global variable on formula