Keeping Salesforce Mobile Apps Running Through Winter, Spring, and Summer Releases

Robbie Westacott
Nov 14, 2017 · 6 min read

One of the most important things a Salesforce partner needs to understand is the annual cycle of releases. Three major updates to the platform are released by Salesforce every year: Winter, Spring, and Summer. These are planned months in advance to a very precise schedule, and each happens automatically.

They affect everyone with mobile apps built on the platform, so the long notice period is intended to give as much time to prepare and test as possible. The release cycle is made available to everyone, and Salesforce admins will be kept up to date by Salesforce’s own email alerts.

This article details the monitoring and testing processes we have in place at MobileCaddy to ensure mobile apps keep performing through any environment changes, including those major Salesforce releases.

Breaking down the Salesforce release cycle

Firstly, let’s take a closer look at how these releases are scheduled and then rolled out to the global community. The cycle for each of these Winter, Spring, and Summer releases runs as follows:

Phase 1: Pre-release updates become available

These have been known to include bugs and breaking issues for apps, so the purpose of the pre-release is to allow for extensive testing. Salesforce’s teams work hard at patching and resolving any problems they find or which are reported.

Phase 2: Sandbox updates become available

These can either be updated early to allow time for testing, or remain stable until the production release date. The latter can be helpful if mobile apps are actively being developed within them.

Phase 3: Released into Production

Which sandboxes are going to be automatically updated, and when, will be explained by Salesforce during the build up. Then, finally, the updates are released into production for everyone at the originally announced date.

How does this affect partners?

All mobile apps will be affected by changes to their mobile environment, including these Salesforce releases, and this often happens outside of your control. Lots of different types of changes to the mobile environment are happening constantly and can’t be avoided, so it’s wise to do everything possible to prepare and ensure there’s less chance of a negative impact.

For all Salesforce partners delivering mobile apps on the platform, pre-release testing before updates are released into production is important, because it will reduce the likelihood of bugs, any problems with integration or custom code, and other causes of app failure.

How can you manage the release cycle?

To avoid issues with environment changes, the best way to manage this is constant monitoring and regular testing. Our team here at MobileCaddy suggests anyone with Salesforce mobile apps should be gaining access to pre-release environments as early as possible, then carry out rigorous testing to ensure no problems come into play.

Our own typical pre-release testing plan used internally for each Salesforce release is as follows:

Step 1: Daily monitoring for availability of pre-release orgs

We start our pre-release testing at the earliest opportunity. This is a pre-defined pre-release test plan which is tuned to the exact dates for each Salesforce release.

Step 2: Daily check to see if prior pre-release orgs have been upgraded

The pre-release orgs will often still be available from the last update. This gives us a headstart in our initial testing, as these orgs can roll over a little earlier than when the new pre-release orgs are made available.

Step 3: Create and configure pre-release orgs

We have a series of org configurations (currently around 15) which provide the foundation for all tests going forward. We then set up different user types (with various licence types, profiles, and permissions), set up orgs with mydomain configured, and create different community types with different community configurations.

Step 4: Initial smoke test

As soon as we have access to either the new pre-release orgs or the prior ‘rolled over’ pre-release orgs, then a rapid ‘smoke test’ for each Container App-supported OS will be carried out.

This brings either earlier confidence or raises issues as early as possible to allow for thorough diagnostics and reporting.

Step 5: Comprehensive automated and manual testing

For each of these configurations, we then go through a series of automated and manual tests, which includes testing against each supported OS and applicable OS versions (which currently include iOS, Android, and Windows 10).

If there are any issues, these will be reported immediately to Salesforce as partner cases. We’ll also write posts on relevant boards and also to internal partner Chatter groups if appropriate.

Step 6: Issue identification and notification (pre-release)

During the pre-release org testing, issues may well occur. As these are identified and confirmed, issues will be raised and assigned, both internally and externally, and any effort assessed should a patch not fix the issue.

By this stage we also add a notification to our MobileCaddy Trust site. If any of our partners or clients have subscribed to alerts and notifications from the Trust site, they’ll receive these by email. It’s worth noting these are just notifications at this stage (not alerts), as it’s highly likely that Salesforce will be patching and remove the issue without any effort.

Step 7: Daily tests for patches or a series of patches

It’s important to keep monitoring and testing. With the environment constantly changing, just because something is working as it should one day, it doesn’t mean you should assume it will still be working the next day.

Once these steps have been taken, we then move to the pre-release sandboxes and run the same tests.

Step 8: Installing into sandboxes

As the first sandboxes are updated to the latest release, we maintain several across different instances. This allows us to carry out the same smoke test and comprehensive test routines as in the pre-release environments mentioned above.

It’s possible that issues will be picked up that are isolated to sandbox environments, so this is an important step, even if we now have a green light on the pre-release production org types.

As MobileCaddy development is performed nearly 100% in sandbox org types, this allows us to test even more build and configure parts of our package.

Step 9: Dealing with any issues in the sandbox

If sandbox issues are found they’ll be confirmed by a different tester, or a different set of tests, to reveal the underlying issue. A ticket will be raised and assigned both internally and externally, and a fix will be planned.

This can turn out to be wasted effort if a patch is subsequently released by Salesforce, but we take an overly cautious view here to always ensure that if a patch doesn’t come we’ll still have a solution ready.

At this point, we also add an alert to our Trust site. Anyone who has subscribed to alerts and notifications from the Trust site will receive these by email. Our alerts make sure everyone is aware of the severity of any issue we find.

Step 10: Updates to ‘Container Apps’ if required

Updates to our Container Apps are more likely to be triggered by an OS version update, but it is possible that a platform change also requires an update to be pushed via the stores and MDMs for the various client Container Apps.

This will be on an app-by-app basis, and a unique, individual timeline would be provided should this be the case.

Step 11: Final checks

Once we’re satisfied with our tests and are happy everything’s secure, we’ll then also test post-production releases on various available orgs to provide one last level of testing and confidence.

Staying ahead of the curve

All this hard work has been done to reassure our clients and partners that their mobile apps will keep running as expected at all times, even while changes to the environment are happening behind the scenes.

The process outlined above is actually pretty easy to standardise and execute, so feel free to try this out for any of your non-MobileCaddy Salesforce apps as well, and be sure to let us know how you get on!


MobileCaddy is an award-winning Salesforce AppExchange Partner, working with some of the leading consultancies in the global ecosystem to deliver more capable, affordable, and reliable custom mobile applications. For more info and further reading, visit: www.mobilecaddy.net.

Inside the Salesforce Ecosystem

Brought to you by Salesforce AppExchange, learn customer and business success insights - straight from leaders in the Salesforce ecosystem.

Robbie Westacott

Written by

Writing about Salesforce mobile apps for MobileCaddy

Inside the Salesforce Ecosystem

Brought to you by Salesforce AppExchange, learn customer and business success insights - straight from leaders in the Salesforce ecosystem.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade