Guidelines on the process of converting the first generation manage package to second generation manage package

Question

We are an ISV and we have a managed package already in app-exchange which clients are already using it for few years. Last year we have migrated our codebase to to sfdx and all are working fine now. Now we are exploring approaches to use second generation packaging. After going through the documentation it is kind of confusing on what is the suggested approach for this. So I have some specific questions on what is the best practice for this process.

1. Let's say we have our existing package namespace as XYZ which is currently assigned in our GA org. Is there any way we can reuse the same namespace. If we use the same GA org what is going to happen to all the versions of our first generation package which we have released before.

2. What is the suggested code lifecycle management for development, testing and deployment for second generation packaging.

3. We are planning to split our code base to multiple reusable component (smaller packages). How are we going to plan to go about it? Specifically we have a set of reusable components which can be shared across multiple managed packages. So we are thinking if the packages can be developed and used as part of a separate DX project, not as a part of the main packages.

4. How is unlocked packages related to 2nd generation packaging?

Please be considerate that we are right now exploring the features. So if this questions are already answered before, please send me some reference to those.

Also if there are any good online resources which provide the step by step approach that will be really helpful. Salesforce documentation does not give a lot of practical examples taking a full lifecycle approach. Also I did not find any trailhead module or project explain the second generation packaging approach.

Thanks, Bikram.

Answer 1

First, some definitions:

Developer Edition Org

A Developer Edition (DE) Org is used for development of personal projects and AppExchange products using First Generation Managed Packaging (1GMP).

Production Org

A Production Org (prod) is used as your primary business org. This is a paid org (or free for some non-profits), both for businesses using Salesforce directly and AppExchange partners selling their products on the AppExchange.

Dev Hub Org

A Dev Hub (DH) Org is used to host Second Generation Packages, both the Unlocked and Managed kinds. It is typically prod that hosts this designation (not a DE org), although a non-namespaced DE org can be used as a sort of "trial" DH org (it has limited capacity for personal/testing purposes).

First Generation Managed Package

A First Generation Managed Package (1GMP) is the classic development model for ISVs. Requires a DE org dedicated as the packaging org, and cannot share namespaces across multiple packages.

Second Generation Managed Package

The Second Generation Managed Package (2GMP) model is the newer version meant to eventually replace 1GMP. Package versions are uploaded to the DH org, not a DE org. The DH Org does not exhibit the contents of the 2GMP (e.g. you can't see the code, tabs, etc in action) without separately installing the package.

Unmanaged Package

Unmanaged Package, a.k.a. First Generation Package (1GP) is a package model that did not allow version upgrades nor allow a namespace, forcing conflicts to be resolved manually. This was primarily meant as a means for moving metadata around a bit easier, and not meant for retail on the AppExchange. They could be upgraded to a 1GMP, but only one per DE Org.

Unlocked Packages

Unlocked Packages, a.k.a. Second Generation Packages (2GP) are for customers/subscribers of Salesforce to manage their own metadata, and not meant for retail on the AppExchange.

---

Let's say we have our existing package namespace as XYZ which is currently assigned in our GA org. Is there any way we can reuse the same namespace.

Yes, you link the namespace to your DH Org, then you can use the same namespace not just for that package, but all packages you may choose to release in the future.

If we use the same GA org what is going to happen to all the versions of our first generation package which we have released before.

Nothing happens to those versions. They will remain 1GMP that can be installed and listed on the AppExchange.

What is the suggested code lifecycle management for development, testing and deployment for second generation packaging.

The same as 2GP development model, but slightly different. You create a Scratch Org, push your metadata there, do development (either in VS Code, another IDE, or directly in the org), pull any changes, commit changes to the repo, and upload a new package version. There's lots of how-to guides out there, the link above is for a Trailhead module.

The only real ISV-specific info that's not in the Trailhead module is that you've linked your namespace, so you need to include that namespace in your sfdx-project.json file. This creates the org as if it were the original packaging org (e.g. it has the same namespace). This alleviates many of the 1GMP problems that plagued developers regarding namespaces. Refer to the documentation for more details.

We are planning to split our code base to multiple reusable component (smaller packages). How are we going to plan to go about it? Specifically we have a set of reusable components which can be shared across multiple managed packages. So we are thinking if the packages can be developed and used as part of a separate DX project, not as a part of the main packages.

You can do this if you want. The common parts are packaged into a 2GMP that contains those components, and then other 2GMP packages can create "dependencies" for that package. This is specified in the sfdx-project.json file. Note that Apex code in the base package can specify @NamespaceAccessible for shared methods without making them global, thus protecting your IP while allowing sharing across packages in your namespace.

How is unlocked packages related to 2nd generation packaging?

It isn't. They're two separate types of packages. See the definitions above, but specifically, 2GMP is used for AppExchange apps, and has several bonus features (e.g. namespaces, post-install scripts, custom documentation links, etc). 2GP is meant to replace 1GP (with better functionality, like upgrade paths), and 2GMP is meant to replace 1GMP.