4

What is the best practices to use multiple dev orgs while developing app that will be distributed as Managed Package with Namespace prefix.

The problem: Once Namespace has been created, there is some problems to deploy code to another Dev Org and do all changes there. SF handles namespace in many places automatically, but in some places not.

For example in Formula Fields, in some dynamic SOQL, of course in custom Javascript and so on, I have to add/remove it when transfer code between orgs with/without namespace.

So far only storing namespace in settings or query it works for APEX and SOQL.

Q: What about Formulas

Q: Is there are any easy way of doing development in multiple dev orgs with namespace in mind?

I have read about Salesforce DX and looks like there we can create Scratch Orgs WITH our namespace. Unfortunately missed the Pilot.

Q: Is it possible to achieve something similar now?

Goal: Do all the development in Dev orgs (without namespace) and deploy changes to Packaging org (with namespace) via IDE. Ideally avoiding of query/check for namespace in every class, manual add/delete to Formulas and sending in to Frontend for Webservice calls.

1 Answer 1

8

The answer to this is to use Salesforce DX, which will be released any day now. DX allows you to create new dev orgs that all share the same namespace as the packaging org. This makes it a lot easier to deal with the namespace, since all orgs you develop and test in will have the correct namespace.

If you don't want to move DX, your next best choice is to develop exclusively only in non-namespaced dev orgs, and use a code versioning system to deploy code from the developer orgs to the packaging org. In other words, never develop in the packaging org, and only dev orgs.

Q: What about Formulas

Write the formulas in your non-namespaced orgs, and do not use the namespace in any of your formulas. They should be properly fixed up when deploying to your packaging org when you deploy to it.

Q: Is there are any easy way of doing development in multiple dev orgs with namespace in mind?

Preferably, use DX. DX will be available any day now. If you can't or won't use DX, you can do this using normal dev orgs, but it requires some strict development practices.

For example, instead of new PageReference('/apex/mypage') in Apex Code, you must use Page.myPage instead. For @RemoteAction, use {!$RemoteAction.className.methodName} instead of className.methodName. And so on, and so forth. Use only namespace-aware functions instead of non-standard "hacks."

Q: Is it possible to achieve something similar now?

Yes, it is possible. However, you must strictly avoid using anything that will break. This means doing your research on what works and what's broken, and avoiding what's broken. For example, inline queries are generally safe without the namespace, as are most class, field, and object references, etc. It just requires more work and more diligence than it would take for a non-namespaced package.

3
  • but SFDX create org that very short amount of time, our QC, Product Owner don't want it. Is there any otherway around this? Commented Dec 11, 2022 at 8:43
  • @manhnt.bkit I don't have enough information to answer your comment. What are your overall objectives? The more information you can provide, the better I can assist. You might even consider actually asking a full question with all the details so you can get a proper answer.
    – sfdcfox
    Commented Dec 11, 2022 at 12:21
  • Thank you @sfdcfox for quick response. I'm using 2nd package development with Buildkite (for CI). After we merged into "dev" branch, our CI will deploy it to our "QC" org. But as we use namespace on our code, when we release to a scratch org this is good. But the scratch org expired in 30 days(maximum). Our QC, Product Owner wanted a consistent org so that they don't have to remember username/login. We tried non-scratch org, but this also got several issues with namespace. Commented Dec 14, 2022 at 15:53

You must log in to answer this question.

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