What’s the proper and efficient way of development for Managed package with multi developers

appexchangemanaged-package

Suppose, several developers are working on the same project. And, we need to create a managed package. Since the managed package has a namespace prefix, the other developers need to develop based on that namespace prefix and put prefix where it is needed. Please refer to the image below (This is what I expect):

Managed Package Expected Flow(Not possible)

However, this is not possible. Because the namespace prefix can't be shared with the developer edition org. Only can be shared with the Scratch org, but Scratch org expires within 30 days, which is more of a hassle.

So, now my questions/concerns are below: (Multi-devs, one namespace for all)

  1. What's the proper way of development for Managed Packages? (I didn't find any straightforward resource. I checked ISV guide, Trailhead, etc. and I'm still confused)
  2. I have tested Scratch org, it can be helpful with my intention, but I find it inconvenient because of the 30 days limit.
  3. I have an Enterprise Edition org, so making multiple orgs/sandbox, etc won't be a problem. So, is there any way I take the advantage of the Enterprise Edition org and achieve what I want as per the image? Or, please guide me if there are any better ways.

Please don't refer link which doesn't clear my confusion or help me with my intention. Thank you!

Best Answer

There are multiple routes to take into consideration here.

Second-Generation Packaging

Your question implies that you’ll be using first-generation packaging (1GP). This is an obsolete and limited packaging technology. As a general rule, absent any specific limitations requiring the use of 1GP, all new packages should be developed using second-generation packaging (2GP).

2GP packages are always developed in scratch orgs using source control, which is a modern best practice.

1GP with Namespaced Scratch Orgs

1GP packages can be developed by a distributed team using namespaced scratch orgs. The thirty-day lifespan of the scratch org should not be a significant problem since your source of truth should be a version control system.

1GP or 2GP without Static Namespace References

If you avoid explicit namespace references in your metadata, you can preserve your ability to deploy managed package source code into non-namespaced orgs, whether scratch or persistent.

This can be challenging to do effectively and often requires a technique like the namespace injection found in CumulusCI (my team’s tooling).

In summary: you are attempting to target a development process that is obsolete and not representative of modern standards and best practices. While there are routes to get some of what you want, your overall experience will be much better if you use the current state of the art: 2GP, source control, and scratch orgs.

Related Topic