Deliver Software as a Service
After completing this unit, you’ll be able to:
- Describe how SaaS has changed the expectations customers have about software updates.
- Discuss the benefits of deploying and maintaining a single version of your product.
- List some things you can do to prepare for updating your product.
Salesforce customers know that they have it good. They don’t have to maintain servers and fiddle with operating systems. They don’t have to know how to design, run, or optimize a relational database. They don’t even have to back up their own data.
They get three major software releases a year with new features and performance improvements. They get copious release notes and training materials (such as this fab Trailhead module). They get AppExchange, a whole marketplace of products that work seamlessly with Salesforce. Everything they need to do their business is right there for them to use.
See? Enterprise software doesn’t have to be painful. It really can “just work.” That is the promise of Software as a Service (SaaS). Over several years, with more than 50 successful releases, Salesforce has kept that promise to its customers. Even major upgrades of the Salesforce platform usually happen smoothly and quietly.
Your customers expect a lot from the products you build on our platform. Hey, that’s what success feels like! So when you update your offering, how can you get it to your customers in a way that keeps the SaaS promise?
Updates come in various forms. Patches are the smallest kind of updates—they fix bugs and make minor adjustments to your product. Upgrades are updates that make bigger changes. We discuss patches and upgrades in the next unit.
When you update your product, you get to choose how your customers get the new version. There are two ways that you can get it into their hands:
- Manual install—Your customers decide when they want the new version and install it using a URL that you provide.
- Automatic Install—You push updates to your customers so that they always have the latest version of your product and everyone always uses the same version. We call this a push upgrade.
At this point, you may be wondering why we offer the self-service option. That’s not how Salesforce does its own releases, and it’s certainly not “seamless.” Why not do things the Salesforce way and update everyone in lockstep?
The reality is this: Salesforce has a long track record of successful, low-drama upgrades. Customers trust Salesforce to do releases correctly, and to quickly fix any problems that can occur in the process. But some of these same customers need more convincing before they’re comfortable with automatic updates from AppExchange partners.
Let’s talk about the benefits of push upgrades, so you can spread the good word.
Push Upgrades Keep It Simple
We recommend that whenever possible, you use push upgrades to distribute new versions of your product, and use self-service updates only for customers who insist on it.
Push upgrades keep all your customers on the same version of your application. That’s good for you and your customers. Why? Consider the alternative: Supporting multiple active versions of your application. When you maintain multiple versions, things get complicated:
- Your support team has to track features and fixes in each version so they can respond appropriately to customer issues.
- You need to maintain multiple versions of your documentation and training materials.
- When you fix a bug, you may have to back port it to multiple versions.
In contrast, when you use push upgrades to keep your customers current, you avoid all that extra work.
It goes without saying, but we’ll say it anyway: Don’t break your app or your customers’ orgs. Of course, updating your product without ruining a customer’s day can be tricky. Salesforce offers you some handy tools and some boundaries to keep you on the right path.
Automate the Process
Sometimes an update requires you to do some work in your customer’s org when your new product version is installed. Maybe you want to validate some data or do some cleanup in the org after the installation.
You could include a button in your app that does the work, but if the customer doesn’t press it, the work won’t happen. Rather than involving the customer, we suggest you just do the work automatically during the installation. When you set up your package, include scripts to do just that. The scripts can update data and certain metadata.
For instance, suppose you find a bug in some Apex code that calculates the value stored in a field. As part of your update, you can fix the bug and run a script that also fixes all of the bad values that were generated before the fix.
Preserve Existing Behavior
When you started working with managed packages, maybe you noticed that you can’t delete certain components that you’ve added to a package (see the ISVforce Guide for a list). If you added a custom object or field to a package and then uploaded that package to AppExchange, you’re stuck with it for now.
That can seem frustrating. But by preventing you from deleting components, Salesforce helps you keep the SaaS promise to your customers. They know they can rely on a certain amount of stability—they can customize and build on your solution without worrying about sudden changes.
Suppose Salesforce didn’t prevent you from deleting components. As part of an update in your app, you delete a custom object from a managed package. If any of your customers use that custom object in a report or have extended it with new fields, they’re in for a rude surprise. They receive your update, that custom object disappears, and stuff breaks. Chaos!
On the other hand, we know that things change—especially in software. Sometimes it’s good to remove a component, whether you’re pruning a feature or redesigning your app. Don’t worry: We’re not going to stand in between you and your goal. There are ways for you to make whatever changes you need to—even deleting custom objects. We show you these in a later unit.
We mentioned Salesforce’s impressive track record of low-drama releases and updates. What’s our secret? Meticulous testing. It’s not super exciting, but it does work. More testing means less drama.
Sometimes partners focus so much on their fabulous new features that they gloss over some details while testing an update. Here’s an example of an incomplete testing procedure: You install your upgraded app on a freshly created empty test org. If it works there, it’s good to go, right? If all of your customers start with fresh orgs, yes.
But most real-world customers are right in the middle of their business at any given moment. They are going to install your upgrade into an org with a million things in it already. So test your upgrades on messy, real-looking orgs as well as pristine ones.
Deploy Your Updates Seamlessly and Silently
Your customers can’t just press “pause” on their business while your software updates itself. That’s not part of the SaaS promise. It’s impossible to guarantee that nothing will ever fail, but you can minimize the chaos by thinking about how your updates affect your customers.
- Consider the impact of your updates. Are you changing the way your customers use your product?
- Test your changes internally first. Use a variety of populated test orgs, not just fresh empty ones.
- Consider using tiers in your deployment: Your power users get updates first, followed by everyone else. Salesforce uses this process, and it helps us understand impacts on real customers.
Now let’s look at the different ways you can deliver your updates.