1

I'm currently working on developing a managed package and have encountered challenges with the upgrade process for Beta versions. When attempting to install a Beta version of the managed package in an org, it seems that upgrading isn't supported, and the package must be uninstalled before a new version can be installed.

However, the "uninstall before installing a new version" approach doesn't seem practical or good to me. I'm exploring alternative strategies, and one idea is to promote each version of the package.

I have a few questions and concerns:

  • Impact of Frequent Promotions: Will promoting each version of the package have a negative impact on the org, and are there any best practices or considerations I should be aware of when doing this frequently?

  • Staging vs. Production Orgs: My package goes through various stages, including staging and production. While most versions are for staging, a few make it to the production org. Is it okay to promote version only install in staging org and this is even might not go through produciton org

  • The limitation APIs: There is limit on promote version. Only 80 times/day might kinda low for staging org enter image description here

I'm looking for guidance and insights into how to manage the package upgrade process effectively, especially during the development and testing phases. Any advice or best practices would be greatly appreciated.

Improve this question

2 Answers 2

Reset to default
2

Beta versions exist to allow you to make experimental changes in your managed package. These changes get "baked in" to the package, in an irreversible way**, when you include them in a managed release (for 2GP, when you promote a beta that includes the changes).

**: with 2GP you can create "branches" of your package, and those different branches may contain entirely different changes. Of course it is not possible to upgrade an installed version from one branch with a version on a different branch, so effectively resulting in much the same behaviour as per 1GP beta releases.

Installed betas cannot be upgraded because the changes in them may not be included in any other version. This also applies to cross-branch scenarios, as above.

However, for testing purposes, it is best to use betas since you may discover significant design issues that require a change that cannot be done in a compatible manner.

Such beta testing works best if you step away from the concept of fixed orgs for staging/testing and adopt scratch orgs. As with scratch org based best practice development, you create a scratch org for each version you want to test with. Unlike dev scratch orgs, it is necessary to use an unnamespaced scratch org so as to mimic a subscriber org.

Since you use a scratch org (with org shape and/or scripting to help you finalise org configuration, including data setup), you never need to upgrade a beta - you simply create a new scratch org with the alternative version.

The key is then that you only promote versions that have been tested and that would go towards production.

Patch versions can be treated identically, using betas initially and subsequently promoting the fix version.

NB: Patching 2GPs requires the package to have passed security review, since Salesforce Support will only enable this capability once it has been through that review process.

Here's an outline of how we work with package development:

  1. We use namespaced scratch orgs on a per-developer, per-task basis. These scratch orgs are created to last at most the length of the development sprint. We do this to:
    • Allow us to deploy/push the metadata from the task's related git branch quickly and easily.
    • Ensure that the scratch org is clean, only including the metadata from the task's related git branch. This avoids cruft being on the org that could affect behaviour and that isn't in the git branch.
    • Be compatible with some of the oddities around certain metadata (I'm looking at you, Flow, and you, Aura) that require explicit namespace references without the need to mangle the metadata during deployment.
  2. We use namespaced scratch orgs for QA for each task. We do this to:
    • Ensure the org contains just the metadata from the git branch to be tested.
    • Avoid the need to create beta releases of the product for every task. We just deploy/push the metadata.
  3. We use no-namespace scratch orgs for QA regression testing before release of a new version. Here, we:
    • Use beta releases (of the new version or a patch, as relevant) and install these on the org.
    • Can ensure that we don't have unexpected behaviour for packaged metadata compared with deployed metadata, in an environment that is closer to a production org in structure and content.

To support this, we created some tooling including:

  1. Scratch org creation and metadata population, including some "unpackaged metadata" (such as perm sets and some testing/demo configuration).
  2. Test data import/export plugin for the SF CLI. This allows QA to have specific data for their manual tests.
  3. JEST UI component testing.
  4. UTAM UI end-to-end testing.
  5. Demo data generation for randomized exploratory testing or quick demos.

Only once we have developed and QAed individual tasks do we then create a beta release for regression testing. Only after we pass regression testing do we promote for version release.

Improve this answer
13
  • NB: Patching 2GPs requires the package to have passed security review, since Salesforce Support will only enable this capability once it has been through that review process. So this mean we can not do patch update unless we contact Salesforce support to enable, is it? Commented Oct 28, 2023 at 18:15
  • Patch versions can be treated identically, using betas initially and subsequently promoting the fix version. so it mean with patch version, we still need to do something like sf package version promote, is it? Commented Oct 28, 2023 at 18:16
  • Yes, patches are also created as betas that must be promoted (2GP). Commented Oct 28, 2023 at 19:02
  • And yes, patching is enabled by Salesforce Support and you do this through a case. But only after passing security review. Commented Oct 28, 2023 at 19:03
  • 1
    salesforce.stackexchange.com/questions/317448/… I found your issue here, I also meet that, but just one small issue. even with create major version with ancestorId setted, this also found issue with package validation like u Commented Oct 30, 2023 at 3:03
1

Based on my experience , I can advise below points :

  1. Will promoting each version of the package have a negative impact on the org ?
  • No , frequent upload of managed packages does not have any documented impact on the org.
  1. As a best practise , upload managed package when it's going to be installed/upgraded to production.
  2. If there are minor changes without any breaking changes (Answer covering limits of patch orgs) , prefer to upload a patch instead of complete package.
  3. Whenever something is being deprecated, major changes in components are added , it is a good practise to increment the major version number (e.g. from 1.4 to 2.0)
  4. I would recommend to stick to a major release number (after freezing major changes like component additions/ access modifier changes etc.) and then uploading patches for small , frequent changes.
  5. After development is completed , you can perform UAT using beta packages. (generally UAT will not have upgrade dependency)
  6. You can typically freeze the major version number after UAT and then work with patches for fixing subsequent integration & upgrade testing issues.
  7. Once package is ready , you can release the last patch to production or appExchange.

Salesforce recommends to use 2GP packaging but it has some gaps compared with 1GP.

Improve this answer
6
  • 1
    ohhh thank you for advising me. Sound like I need to research and integrate versioning in workflow to enhance it Thank you so much, I appreciate it Commented Oct 26, 2023 at 6:20
  • @vctqs1 : Yes , having CI/CD helps in release process. 2GP is more friendly from CI/CD perspective. Commented Oct 26, 2023 at 6:27
  • Also, having question from me. As I searched, the patch update also limit in some specific changes. so in that case. we should provide a minor instead, is it? Also w patch update, we dont need do promote version. right? How about if I increase build in major.minior.patch.build? Do it work? Commented Oct 26, 2023 at 6:34
  • If by promotion you mean listing on appExchange or using on production , it is optional to promote major/patch version.Also , I doubt we can have numbering like major.minior.patch.build for 1GP package. Also , the last number is always the patch number. It can't be build number. For 2GP , this doc gives some insights. Commented Oct 26, 2023 at 6:52
  • ohmm about creating new version number, I'd like to do something automation on CI/CD, there are any ways or cli, that able to auto-detect the changes and create correctly version number with patch or minor or major? something like this? Commented Oct 26, 2023 at 7:27

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.