Partitioned Versioning Enables Risk-free Production Upgrades to Salesforce Mobile Apps

Traditional deployments of updates to mobile applications are hard, and harder still in the enterprise world. Mass, uncontrolled updates to users are risky at best. Partitioned Versioning, with MobileCaddy, enables a low impact, highly iterative, approach to application update deployments which minimises the risks.

Mobile applications need to be updated for many reasons. It’s common for an initial release of a new app to contain bugs that weren’t caught in sandbox and developer environments, for example, or for a misunderstanding of workflow to pass through the UAT stage unnoticed.

Beyond this, once an app is live and mature, it will still need to evolve in line with many factors including (but not limited to): new business requirements, regulatory updates, alignment with new OS and hardware capabilities, and of course in our world modifications to support new Salesforce releases.

Changes to mobile app4

Unfortunately, Salesforce mobile applications limits you to an all-or-nothing upgrade approach, replacing an existing app with new versions to all users. This is of course risky in reference to having no control – or reporting – over which users have updated. It also brings the challenge of managing the app store submissions.

With Partitioned Versioning from MobileCaddy, you get a prescribed methodology for updating your mobile applications. Included is the ability to run multiple versions of an app in a single instance (org) and target versions to specific users’ devices.

This enables the following across all org types (Developer, Sandbox, Production):

Smoke Testing

Existing “GA” Dynamic Versions are those that are automatically provisioned to new users, whereas new DVs can be set to “Testing”. Once in this state they can be manually provisioned to specific users’ devices, ideal for running full integration tests in production environments.

Partition_Verisons_Production

Over-the-air Updates

Limited, controlled rollout of updates are Over-the-Air (OTA), and are built so they won’t take place if there is data that still needs to be synced to Salesforce. They won’t interrupt the user during critical workflow processes either. OTA updates skip the need to re-submit to app stores (iTunes, Google Play etc) and it is very common that most app updates can be performed via this method.

Over_the_air_updates

Container_Store_Updates

It’s clear that Partitioned Versioning has value. That value only increases when you look at a typical scenario across enterprise software projects.

Let’s say the first drop of our app is out the door, and as soon as that happens our team is disbanded, with SAs, lead developers, and BAs all being pulled straight onto other projects. You’re now in a position where your app has a large active user base, but these first-drop CRs (Change Requests) and tickets are being raised. The structured MobileCaddy approach allows changes to the app to be made, and speedily make their way through to production release with the minimal amount of risk to the current running version.

The bottom line

A complicated or hazardous update process can cripple a business’s ability to react to new and changing requirements, and support the rollout of bug-fixes. Any CTO found being held ransom by such a setup knows this all too well.

MobileCaddy has attacked this issue head-on, from the inside-out. Partitioned Versioning means that not only are initial versions of applications deployed with ease, but so are updates and fixes, with a growth in confidence through each stage of the process.

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