5

Are you using push upgrades for your app, meaning your customers get your app changes when you want rather than when they want? (Just like we all get 3 new versions of the platform a year.)

Any gotchas with this approach?

Improve this question

2 Answers 2

Reset to default
6

I am a release engineer at Salesforce.org, an internal ISV - that is, we are part of Salesforce but build and deliver managed package products like any other ISV does.

We use push upgrades on a massive scale (entire customer base every two weeks). I can't quote you customer numbers, but we've been running this program for years across a very large number of subscribers.

Key Benefits

  • Most customers are on the same version of the product, massively reducing support needs to upkeep older versions.
  • We very rarely need to issue patch versions because we don't maintain old package versions - we just upgrade them. We have one code line, not dozens of patch branches.
  • New functionality is delivered to customers on a predictable schedule.
  • You can get relatively close to a continuous delivery model.

Key Gotchas

  • Push upgrades do not succeed at 100%. There is a long tail of customers whose orgs are somehow borked internally and who cannot receive push upgrades of your package. It's still well worth it for the high-90s percent of customers that do reliably get every upgrade, and different packages will have very different risk exposures.
  • For owners of multipackage suites, there is no automatic synchronization or dependency resolution across package dependencies. If you need to push Packages A, B, and C, where B depends on A and C depends on B, it's a manual process for your release engineers to ship them on the right cadence to satisfy the dependencies in the new versions. I do that by offsetting each push by a number of hours and then repushing each serially the following day for a sort of eventual consistency model.
  • Moving into a push upgrade model and negotiating the existing relationship and expectations with your customers may be a challenge.
  • The push upgrade interface is antiquated and quirky. Using an API client helps mitigate this (the Tooling API can support push upgrade operations).
Improve this answer
6
  • Thanks David. As you have guessed, we would be going from non-push into push, and we are drowning in patching work.
    – Keith C
    Commented Mar 23, 2021 at 14:33
  • I own two legacy products that are not on push upgrades, and I've talked with a number of other ISVs in the same position; not having to maintain patches at all is an absolutely massive benefit. I issue patch versions for my mainline products only if we accidentally flub the two-stage delete process on a component.
    – David Reed
    Commented Mar 23, 2021 at 14:42
  • Thanks David. Have you or anyone else you know of managed to move a not on push package to a push one? One factor for us is that our customers expect to do UAT on software, perhaps because of the tradition of a big pile of changes hitting all at once. The frequent small change approach seems way less risky to me.
    – Keith C
    Commented Mar 23, 2021 at 15:25
  • I wish I could offer a case study but no, I don't have any transition stories at all. We've now moved from a pure biweekly push to a biweekly minor release, with major changes aggregated to a thrice-yearly seasonal release (also pushed) that comes with more lead time for customers to test.
    – David Reed
    Commented Mar 23, 2021 at 15:32
  • We do always push to sandboxes first and provide customers with a testing window of at least six days before the production delivery. For seasonal releases, the testing window is longer.
    – David Reed
    Commented Mar 23, 2021 at 15:32
3

We do use push upgrades for our managed package. I think it is crucial, especially when you use API in your package and need to remove some deprecated endpoints etc.

Also it is important for customers to stay up to date with the package version to get precise and efficient support.

Moreover, sometimes there are scripts in InstallHandler that are connected to specific version and if users upgrade package manually (skipping several versions in between) these scripts should be run manually too (it's a pain to keep track on such occasions).

Nevertheless, we have several clients, who informed us that they want to upgrade package only manually, so we omit them in push upgrades.

No gotchies so far. Even if new version can have some issues, we can push correct one right of the reel.

Improve this answer
1
  • Thanks Mariia - helpful.
    – Keith C
    Commented Mar 23, 2021 at 14:07

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .