Learning objectives
Monitor your orgs for configuration changes with Gearset
Detect and roll back unwanted org changes
Automate Apex unit testing
You will need
To have completed Modules 1 - 3 (Gearset app fundamentals, Mastering metadata filters, Gearset's problem analyzers)
The admin nightmare
The only constant in a Salesforce org is change. Platform updates, new features and bug fixes are constantly flowing between sandboxes and production. Depending on how fast your team operate, releases might be going out multiple times a day. Tracking all these changes is hard. Let's illustrate with an example.
It's Monday morning, and you get a message from a colleague saying they accidentally modified one of your key profiles while trying to change a permission. And they did it in production! They want to get things back as soon as possible as their team has lost access to all of their support cases and sensitive customer data is accessible to other teams. As the admin responsible for the org, it's up to you to fix it. What do you do? How do you know what state that profile was in, and what it should be? How quickly can you restore the correct permission levels?
In Salesforce natively, you don't have many options. It will show you exactly what you profile looks like now, and who last changed it, but not what it looked like yesterday. You could try and deploy the settings from your sandbox, but who knows whether they're correct. Your best hope is to dig up a spreadsheet or screenshot of the profile settings to reference, otherwise it's a painstaking process of rebuilding it by trial and error. Not a good start to the week. If only there was a better way...
Automating change tracking
In the modules before this you've explored how Gearset can compare orgs, deploy changes, roll them back, how to use custom filters to control what you see, and understand how its problem analyzers operate. Now it's time to look at some automation.
Gearset's monitoring jobs track configuration changes to a Salesforce org and produce daily reports on what's changed. Each day they'll take a new snapshot of the org, compare it to the last one, and highlight all the differences.
Let's see how it works.
In the Gearset menu, click Monitoring in the automation section to open the monitoring dashboard
Click Add new job
Set the run time as 10 minutes from now
Name the job: Source org monitor
Set the organization to your source org
In the Notification settings tab, set the job to notify you only when there are changes, and enter your email address
Leave the metadata filter setting on its default settings
Click Save
You've now created your first monitoring job. Gearset will take a snapshot of your source org's configuration as a baseline for future comparisons. In approximately 10 minutes, when it hits the scheduled time, it'll take another snapshot to compare against and highlight any differences between the two. You've got 10 minutes to finish the next few steps!
Let's replicate the scenario at the start.
In a new tab in your browser, log into your source org, open the setup menu and navigate to the profiles section
Find the Custom: Support Profile item and click Edit
Under the Standard object permissions, remove access to the Accounts and Cases objects by unchecking the boxes, and click Save
Done, phew! Time for a quick break. Go grab a cup of tea and wait for your scheduled job start time while keeping an eye on your email inbox.
If you didn't get time to complete these steps before the snapshot was taken, don't worry. On the monitoring dashboard page, click on your job to expand it out, and click Snapshot metadata. The job will take a new snapshot of your org on demand.
A short time after your job's scheduled start time, you'll see an email arrive from Gearset. It looks like something has changed in your source org!
Click the View comparison link from the email to dive right into the change comparison. You'll see 8 deleted components, all relating to custom object permissions and profile changes that have been changed
Rolling back unexpected changes
Imagine you're back on that fateful Monday morning and you've just received that message from your colleague. Let's see how life is different with Gearset.
Navigate to the monitoring dashboard in Gearset. You'll see the status of your job has changed to Different. This looks worth investigating.
Click View history to open the job's snapshot history. There will only be one run which is showing 8 deleted items. Could this be the change your colleague made?
Click View comparison to have a look. You'll see your source org at two snapshots in time (around 10 minutes apart in this instance). And from looking at the XML, it seems like these could be your accidental profile deletions! Time to set things right
Jump back a level to the job's snapshot history, and click Roll back, then Start rollback comparison
In the resulting comparison you'll see the snapshot of your org as it was a few minutes ago compared to its current state. All of the permission changes appear as new items - if this sounds strange, remember that they used to exist in the snapshot and were removed, so this deployment will be putting them back again
Select all the changes and deploy them out, adding a deployment name and notes along the way
Once the deployment has completed, refresh the window in your Salesforce source org and check the status of the profile. Phew, all back to normal. Crisis averted!
Note: To make it easier navigating between change monitoring job, use the Previous Comparison and Next Comparison buttons at the top right corner of your comparison screen.
Monitor all your key environments
Monitoring jobs are a powerful tool to get insights into the ever changing state of your orgs. Once they're set up, they'll run every day and let you know if anything changes. And with their customizable notification settings, you can have the notifications sent to Slack, Microsoft Teams, or Chatter so they're visible to the whole team.
There isn't a limit to how many monitoring jobs you can create in your Gearset account, so it's worth setting at least one up for each of your key environments: production and pre-production are good starting points. You can even create multiple jobs per org to alert different teams to different configuration changes - why not have one watching Apex and Visualforce for your development team, and one watching profiles for your admins?
Apex unit testing
Monitoring configuration changes isn't the only string to Gearset's bow. It can also track the status of your unit tests across multiple orgs and alert you when anything goes wrong.
If you've worked with the Salesforce platform you'll have come across the infamous 75% code coverage requirement that Salesforce enforces on any Apex code in production orgs. In essence, for every 100 lines of code you write, 75 of them must be checked by an automated test to ensure they're doing what you expect (and those tests must pass!). This isn't an arbitrary requirement by Salesforce, but an important coding principle.
As Eric Kintzer, the co-author of Gearset's whitepaper on static code analysis, puts it: "unit tests are important because they help demonstrate intended behaviour and functional correctness of your code. They can also make your code easier to change by encouraging you to write more loosely coupled, modular code, and by providing an early warning of any bugs that might creep in when making changes. Code coverage is a great way to ensure that the bulk of your Apex is under test."
In an ideal world, each Apex class has its associated unit test, and that test always passes. The challenge comes when, inevitably, tests start failing. If you are pushing code into production, a single failing test can stop the whole deployment. That's not ideal if you're on a timeline and need to get your changes out.
You might think any test failure would always be caught before it got to the production release as part of testing, but it's all too easy to end up with test issues:
You want to deploy a new Apex class which has low code coverage but a passing test. When you try to deploy it to production, it lowers the overall org code coverage below 75% and the deployment is rejected
Salesforce doesn't automatically run tests when pushing changes to non-production orgs, so broken classes can easily slip through the net
As it happens, testing is another place where Gearset's automation can help out.
Automating unit tests
The best way to spot test failures or low code coverage is to regularly run all your tests in each of your orgs. It is possible to do this through the setup menu of each org, but there's no way to schedule test execution and no way to track trends or notify people of the outcomes. Enter Gearset.
In the Gearset menu, click Unit testing in the automation section to open the unit testing dashboard
Click Add new job
Leave the job run time at midnight, and decide which days of the week you want it to run
Name the job Target org testing job
Select the target org from the dropdown
Leave the code coverage and namespace fields at their default values
In the notification settings tab, select notifications only when tests fail and enter your email address
Click Save
For each day selected, at midnight local time, Gearset will run all of the tests in your target org and track the results. If any tests start failing, you'll get notified.
As this is an empty org, there aren't currently any unit tests in it so the job won't return any results. Let's add one to see the job in action.
In a new tab, log into your target org
In the setup menu, navigate to the Apex classes page. Your org doesn't have any classes in it, so let's go ahead and add one
Click New
In the Apex editor, paste in the code below and click Save
@isTest
public class FailingTests {
@isTest static void test1() {
System.assertEquals(2, 1);
}
@isTest static void test2() {
System.assertEquals(1, 2);
}
}
You should have a new Apex test called FailingTests (guess what this might do!)
Back in your other tab in Gearset, click the play button to run your unit testing job right now. Gearset will now re-run all of the tests in your org and report the results
After a minute or so, refresh the page and you should see your job now shows an updated status of Tests failed. What a surprise! You'll also find an email in your inbox confirming the bad news
Click View history to explore the full history for this testing job. Notice the first entry with "No tests found", and the most recent showing "Tests failed". Just like change monitoring jobs, each time this job runs in Gearset it will track the result so you have a full history
Click View results on the top row to see exactly what's gone wrong. You'll be able to see the exact error messages from Salesforce for each test
Best go fix up this test! In your target org, in the Apex viewer window that you have open, click Edit to open up the Apex editor again. Select all the code and delete it, then replace it with the code below
@isTest
public class PassingTests {
@isTest static void test1() {
System.assertEquals(1, 1);
}
@isTest static void test2() {
System.assertEquals(2, 2);
}
}
Click Save
In Gearset, run the unit testing job again, wait a minute or so, refresh the page, and check the results. Click through to the run history to check the results of your tests
The good news is our tests have started passing. The bad news is the overall code coverage in the target org is a pretty measly 0%. We'll leave fixing that up for another day
In this module you've explored how to set up some of Gearset's automated jobs, their features, and how they help you manage your environments. In the next module it's time to look at working with version control.