How MobileCaddy Keeps Your Custom Mobile Apps Running Through Every Salesforce Release

This article will detail the monitoring and testing processes MobileCaddy has in place to ensure mobile applications continue to perform through any environment changes, including the Salesforce releases which occur three times each year.

sf_release_cycle

An overview of Salesforce releases

Three times per year, a major Salesforce release occurs which introduces updates to its software. These releases happen automatically and affect everyone within the ecosystem, including regular customers and ISV partners with related solutions such as MobileCaddy.

These spring, summer, and winter releases are planned months in advance and are kept on a very precise schedule to allow for as much preparation as possible. The release cycle is made available to everyone, and Salesforce administrators are alerted via Salesforce’s own email alerts for admins.

Breaking down the Salesforce release cycle

Once the dates for the production release have been agreed and announced, the release cycle runs as follows:

  • Pre-release updates

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

  • Sandbox updates

    Following that, Salesforce releases its sandbox updates. By following Salesforce’s sandbox release guides, 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 projects are actively being developed within them.

  • Released into production

    Details of which sandboxes are going to automatically update, and when, is provided by Salesforce during the build up to the release. Then, finally, the updates are released into production for everyone at the previously-mentioned announced date.

Why should you be concerned?

The Salesforce platform is a crucial part of the mobile environment, and it will change without your control. It’s important to note that changes to the environment in which your mobile applications exist happen regularly, and are inevitable, so the only thing which can be done to minimise their impact is to prepare.

If no pre-release testing is conducted before these updates are released into production, it’s highly likely mobile apps will encounter issues when moved into the sandbox or even once they go live. If these problems go unnoticed, it can affect integration, it can cause problems within custom code, and ultimately it can cause apps to fail.

How MobileCaddy manages this 

MobileCaddy’s stance on environment management is to put constant monitoring in place for anything which can change. We advise that anyone with mobile applications built on the Salesforce platform should be gaining access to pre-release environments at the earliest possible time, then carrying out extensive testing through numerous configurations to ensure no problems come into play.

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

  • 1

    Daily monitoring for availability of pre-release orgs

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

  • 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 Salesforce update. This means we can get a headstart in our initial testing, as these orgs can roll over slightly earlier than when the new pre-release orgs become available.

  • 3

    Create & configure pre-release orgs

    We have a series of org configurations (currently around 15) which are set up to 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.

  • 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 operating system will be performed.

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

  • 5

    Comprehensive automated and manual testing

    For each of these configurations, we then run through a series of automated and manual tests, including testing against each supported operating system and applicable operating system 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 publish posts to relevant boards and also to internal partner Chatter groups where appropriate.

  • 6

    Issue identification and notification (pre-release)

    During the pre-release org testing, issues may well be encountered. 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.

    At this point, we also add a notification to our Trust site. If you’ve subscribed to alerts and notifications from the Trust site, you’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.

  • 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 we can 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.

  • 8

    Installing into sandboxes

    As the first sandboxes get updated to the latest release we maintain several across different instances. This allows us to perform the same smoke test and comprehensive test routines as in the pre-release environments 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 may now have a green light on the pre-release production org types.

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

  • 9

    Dealing with any issues in the sandbox

    If sandbox issues are encountered they will be confirmed by a different tester, or a different set of tests, to understand 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 is not forthcoming we’ll have a solution ready.

    At this point, we also add an alert to our Trust site. If you have subscribed to alerts and notifications from the Trust site you’ll receive these by email. Our alerts make sure clients and partners are aware of the severity of any issue identified.

  • 10

    Updates to Container Apps if required

    Updates to Container Apps are more likely to be triggered by an operating system version update, but it can be 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 a client-by-client, app-by-app basis, and you’ll be notified and provided with a timeline should this be the case.

  • 11

    Final checks

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

Staying ahead of the curve

This is how we at MobileCaddy manage the Salesforce release cycle, to keep your apps running as they should throughout any environment changes. This is to give you, our clients and partners, full confidence in their performance at all times.

We’re always happy to provide full visibility into what we’re doing both on the surface and under the covers. The process outlined above is fairly easy to standardise and put into practice, so as a client or partner this could also be used for any of your non-MobileCaddy applications. Of course, for all apps built with the MobileCaddy Application Delivery Framework, all this hard work is done for you.

This is just one element of a far wider scope of environment monitoring and testing, but is an absolutely crucial thing to do to ensure you don’t have any risk or worry attached to your critical Salesforce mobile apps.

Operating System Android vs Apple

For another example and further insight into how MobileCaddy handles environment changes, see how we manage updates to mobile operating systems to keep your applications running with full confidence.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Scroll to Top