Upgrading Classes Efficiently

Blog:

As developers, it’s our duty to provide support to our companies and clients for things they may not even understand needs attention. I prefer to think of Salesforce orgs as living beings. They can be spawned from other instances, often contain attributes which make each of them unique, and, if not cared for properly, can result in their untimely demise. It’s our responsibility as developers to educate our management on how some tasks we perform will not provide immediate payback but are essential to long-term health of the system. I’ll be covering a simplified way of handling API level upgrades as Salesforce releases new editions three times a year.

Why?

It may sound counterintuitive to upgrade classes which are working perfectly fine. It may sound even more counterintuitive to spend resources on something that doesn’t provide tangible, immediate, benefit to an organization. I recall dozens of conference calls where clients opted out of performing these upgrades only to regret it years later. Upgrading classes allows organizations to both capture new features available in every release and eliminate potential bugs found in older ones. Not doing so on a regular basis (at least once a year) can prove fatal in your long-term development efforts, nothing short of potential reimplementation if it gets bad enough.  

It’s not explicitly written on any Salesforce documentation but heavily debated by respected members of the Salesforce community that each class/trigger invoked in Salesforce requires that specific emulated model of rules and features. It’s not difficult to then imagine an org that has 20 difficult versions in a single call (yes, I’ve seen them) where it’s painstakingly slow to operate in. Imagine waiting 10-15 seconds just to save a phone number change to a lead? It could be loading a handful of triggers and tandem logic which all have varying API levels, but the system still has to generate them all in order to process anything. I’ve seen user adoption drop in organizations where management either doesn’t understand the need or willfully ignores it until it’s too late. Even the best algorithms can’t save a system which isn’t maintained well.

Word of Caution

When making these upgrades, it is good to fully test everything even when you have plenty of test classes supporting you. If not, your users may see some strange bugs that affect their day-to-day work (for instance, queries failing out of nowhere as described in this issue). Coming up, I’ll show how to quickly upgrade as many classes as you want, but this shouldn’t be done so lightly.

How?

Now that we’ve established why this should be done, we’ll cover how. There are a handful of ways to do it. I’m going to show you my preferred method, which I find to be simpler than all the available ones. To preface this, we at Chicago Cloud Group write test classes for both Apex and our Process Builders/Workflows. We do this to automate package upgrade testing and API level upgrades. Spending a little time upfront like this saves us hundreds of hours of work in the long run.

To start off, you’ll need to get a quick feel for your org. At the time of writing this, API version 48 is currently available and is the latest. To do so, you can quickly run this query in your org.

SELECT Id, Name, NamespacePrefix, ApiVersion 

FROM ApexClass

WHERE ApiVersion < 48.0 AND Status = ‘Active’ AND NamespacePrefix  = ”

Next, you’ll want to write a package.xml file which we will use as the driving logic behind which classes you’re going to upgrade. The first instance shows how to get all classes. This will retrieve both classes you’ve modified and unmanaged packages. It’s recommended to list classes individually like the second example.

<?xml version=”1.0″ encoding=”UTF-8″?>

<Package >

    <types>

        <members>*</members>

        <name>ApexClass</name>

    </types>

    <version>48.0</version>

</Package>

<?xml version=”1.0″ encoding=”UTF-8″?>

<Package >

    <types>

        <members>MySpecialClass</members>

        <name>ApexClass</name>

    </types>

    <version>48.0</version>

</Package>

Next, you’ll want to use the Workbench by logging into it here. Make sure you’re logging into the sandbox while in the testing phase.

You’ll want to go to the “Migration” tab and select “Retrieve.”

Then you’ll want to upload the package.xml file into the webpage below and click “next.” You’ll be asked to confirm the request.

Once the process is complete, you’ll have the chance to download the zip file.

I’m personally using Sublime Text as my preferred editor outside of VS Code, but there are many ways to do the next part. You’re able to upgrade all classes in each directory with a single call. In Sublime, you can drag over a folder and see all the directories/files below. Then you’re able to go to Find -> Replace and paste in this regex “<apiVersion>(.*?)</apiVersion>” without quotations. Make sure to click the Regex button in the bottom left.

Finally, we’re able to zip up this folder and upload it as a deployment through the workbench. Simply go to the Migration tab, and click deploy instead of retrieve. Below, I checked the box which says “Rollback On Error” just in case there is an issue. Click Next and then click Deploy.

The program will tell you once it’s complete and then you’re free to start testing. You’re able to use this method on all your orgs repeatedly and even your production org for everything that worked. Happy testing!