1

We have a 2nd generation managed package with no dependencies that we develop on dev, qa, and prod branches. Only packages built from the prod branch are ever available to customers.

I would like to create and promote new package versions in the dev and qa branches to allow testers to upgrade but not introduce new metadata components in the "prod" package that cannot be removed.

It seems like branch ancestry should work but doesn't actually support this use-case.

Although more than one beta package version can have the same version number, there can be only one promoted and released package version for a given major.minor.patch package version.

https://developer.salesforce.com/docs/atlas.en-us.232.0.sfdx_dev.meta/sfdx_dev/sfdx_dev_dev2gp_use_branches.htm

How can I setup package ancestry such that I can maintain 3 separate branches of my package indefinitely.

6
  • 1
    It's unclear that you need to promote the beta versions until they're ready for prime time. Sandboxes and Scratch Orgs don't require promotion to install.
    – sfdcfox
    May 5, 2023 at 19:50
  • 1
    Have you considered mapping the same source folder to multiple different packages for the different usages by defining multiple packageDirectories against the same path but different packages in the sfdx-project.json? Being different packages (with the same namespace) you have more control... not 100% sure this will work, but have seen suggestion it should.
    – Phil W
    May 5, 2023 at 21:27
  • @sfdcfox - Our issue is that you cannot upgrade from a beta version. There's a lot of setup involved in the package and it integrates with an external system so we have long-running test orgs rather than spinning up new ones every sprint. May 8, 2023 at 15:26
  • @PhilW - That's an interesting approach. So there would be a dev / qa / prod folder in the sfdx project? The one big issue I can see is diffing / merging. Not really a traditional git workflow. May 8, 2023 at 15:28
  • 1
    No, the code all exists in a single folder, only the sfdx-project.json maps it to multiple, different packages. You can choose to use different branches to vary the content of the packages, choosing to merge as and when appropriate.
    – Phil W
    May 8, 2023 at 20:33

1 Answer 1

1

Have you considered mapping the same source folder to multiple different packages for the different usages by defining multiple packageDirectories against the same path but different packages in the sfdx-project.json?

The concept is to have a sfdx-project.json akin to the following:

{
  "namespace": "mine",
  "sfdcLoginUrl": "https://login.salesforce.com",
  "sourceApiVersion": "57.0",
  "packageDirectories": [
    {
      "path": "force-app",
      "default": true,
      "package": "Prod",
      "versionNumber": "1.1.0.NEXT",
      "ancestorId": "[email protected]",
      "definitionFile": "config/project-scratch-def.json"
    },
    {
      "path": "force-app",
      "default": false,
      "package": "QA",
      "versionNumber": "1.3.0.NEXT",
      "ancestorId": "[email protected]",
      "definitionFile": "config/project-scratch-def.json"
    }
  ],
  "packageAliases": {
    "Prod": "0Ho3...1",
    "[email protected]": "04t3...1",
    "QA": "0Ho3...2",
    "[email protected]": "04t3...2"
  }
}

You would then branch as needed, merging changes into branches of interest and explicitly building new versions of the relevant package ("Prod" or "QA" in my example) depending on the branch you have checked out - you could build some smarts into a script that does the build where it looks for "Prod" or "QA" (or some other environment) in the checked out branch's name to help avoid human error.

You'd need to ensure that relevant changes in the sfdx-project.json get merged up through your branches as part of the over-all branching and merging strategy.

All these packages share the same namespace and will have the same content, so cannot be installed on the same org together. However, you would target one flavour of the package in any one org anyway.

NB: I'm still not 100% sure it will do what you need, but give it a go.

3
  • I implemented it differently, but I can attest that the basic strategy of using alternate packages you're articulating here works just fine to achieve Greg's goal. (I did it with Unlocked Packages as the alternate package shape for upgradeable test orgs).
    – David Reed
    May 9, 2023 at 17:02
  • @ PhilW, @DavidReed, instead of having separate packages for the same force-app folder, could I have separate version numbers of the same package, with different ancestorId mimicking different branches ? For unlocked packages, I could add the explicit "branch" property : would this work ?
    – altius_rup
    Oct 18, 2023 at 14:18
  • 1
    You probably could, but managing this becomes difficult since you effectively add "hidden" semantics to those version number streams. E.g. 1.x.y is prod, 2.a.b is UAT etc. which is non-obvious.
    – Phil W
    Oct 18, 2023 at 14:27

You must log in to answer this question.

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