3

Thanks in advance.

I have a few questions related to Salesforce environment strategy. Generally for enterprise customers I have strategize something like DEV -> QA -> UAT -> PROD. I would like to know how would same strategy can be leveraged w.r.t. SFDX for ISVs as it involves Partner dev org which holds a namespace prefix which once linked with dev hub org, scratch orgs can be provisioned to work with namespace prefix. But how would it be applicable for sandboxes. Will the same strategy work for ISV partners who wants to use DX? It would be a great help if someone can elaborate the strategy.

Improve this question

1 Answer 1

Reset to default
2

Sandboxes are not, and never have been, designed to support Managed Package development. People did so only because Developer Edition orgs were painful enough to work with and coordinate, that ISVs would rather have used Sandboxes. No longer is this true. Unlike Sandboxes, Scratch Orgs always come as a clean slate. This means no accidental dependencies to installed packages, no leaking internal metadata configurations on standard objects to your package, no "experimenting" with dynamic code depending on if a namespace is detected... the list goes on.

ISVs should not attempt to use Sandboxes for developing their product. This is 2019 (future visitors, insert current year here), and we finally have a robust set of tools that we've been asking about for nearly a decade or more (for example, this idea which DX actually solves in a meaningful way). If you are a customer doing customer things, do continue to use Sandboxes if you'd like. They're a perfectly natural way to operate. Or, migrate to Unlocked Packages, and you can still use Sandboxes or upgrade to Scratch Orgs.

Please, do yourself a favor and drop the notation of using Sandboxes for your ISV development. Too many things can, and often do, go wrong, no matter how carefully you tread. Using DX, Unlocked Packages, and Scratch Orgs is definitely the way to go in to the future. If you want to use Sandboxes for any part of the development life cycle, I suggest limiting such use to QA and UAT--those steps should never involve editing code, and Sandboxes can install managed packages. You should do this anyways as a smoke test to make sure that nothing breaks when a subscriber installs your package.

There are a few ways to go about it, rather than one "best" way, but it seems that, for the most part, the ISV release cycle goes a bit more like this: DEV Scratch Orgs -> QA Scratch Orgs -> UAT Scratch Orgs -> Partner Dev Org -> Upload Package -> Sandbox Smoke Test -> Release to AppExchange. Not all ISVs will use all these steps, nor are all steps strictly recommended, but this should be considered a comprehensive development strategy for most ISVs, and those that are using DX most likely have some or all of these steps (and possibly a few more, such as Continuous Integration/Continuous Delivery).

Improve this answer
3
  • Thanks @sfdcfox.
    – Lokesh Gupta
    Commented Aug 26, 2019 at 11:40
  • there is another question - how would I involve QA people for manual testing? How to provide the access to UAT (scratch org) is not clear to me.
    – Lokesh Gupta
    Commented Aug 26, 2019 at 17:01
  • @LokeshGupta There's a CLI for that: force:user:create. You would use this as part of your shell script to create a new scratch org. Depending on the type of org you create, you'll have a limited number of licenses, but this should be suitable for most purposes, even QA or UAT. You can also manually create users as you would in any other org, or use the API (e.g. Apex Data Loader) after setting the password (force:user:password:generate).
    – sfdcfox ♦
    Commented Aug 26, 2019 at 18:24

You must log in to answer this question.

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