Still you are in the path of linear development through conventional First Generation Packaging (1GP) !!!
A new way to develop, distribute, manage apps and metadata for AppExchange is there. Yes you are right, The 2GP, Second Generation Packaging.
Salesforce now has two ways to package an app: First Generation Packaging (1GP) and Second Generation Packaging (2GP). It is built in aligned with SFDX. As SFDX is a recent development environment with full package of benefits for Dev team. As a outcome, 2GP and SFDX combination are modernize the package development and deployment system. Consequently, to use 2GP you must use SFDX.
💦 Advantages of 2GP :
Developing a package with SFDX have many Advantages over 1GP, that make sense for a partner to choose 2GP over 1GP. Let’s try to find out the advantages, OK ?
💡 Packaging supports Branching :
In 1GP, you should merge your code with base source before doing any code changes. Now branching option available through 2GP that gives developers, a liveliness to develop any new features.
💡 Namespace :
A namespace is a 1–15 character alphanumeric identifier that distinguishes your package and its contents from other packages in your customer’s org. A namespace is assigned to a package at the time that it’s created, and can’t be changed.
Namespace is used to ensure to avoid the component names conflict between apps from different partners.
In 1GP, the Namespace was tightly coupled with specific package. So in that case there are multiple namespace for multiple packages ! that create a complexity automatically.
Now in 2GP, namespace is a 1–15 character alphanumeric identifier that distinguishes your package and its contents from other packages in your customer’s org.
Practically partners can define one Namespace for their company and use it for all package they want to develop.
Namespace is assigned to a package at the time of creation, and can’t be changed.
💡 Modular Approach :
In 2GP, we are able to crumble our app to separate modules. In this way smaller type of functional modules have some benefits like easier to develop, debug, very low risk at releases, etc.
But 1GP follow the monolithic applications approach, where every feature of the application represented by a single package.
💡 Package Ownership :
In 1GP packaging org owns the package. The metadata in the package resides in the packaging org.
But in case of 2GP Dev Hub owns the package, but the Dev Hub doesn’t contain the packaged metadata.
Its recommend that we should enable Dev Hub in our Partner Business Org (PBO) for 2GP.
💡 Source driven mechanism :
1GP works with Source Control, but ultimately the application Source of Truth resides inside the 1GP Packaging Org.
In 2GP, version control system is the source of truth (source-driven system) for the metadata in our package.
Unlike 1GP, 2GP doesn’t use packaging or patch orgs.
💡 Automated Approach :
In 2GP All packaging operations can be automated using Salesforce CLI. But in 1GP Some packaging operations, like package create and package uninstall, can’t be automated.
💡 Patch Versioning with CLI :
Patch versions are created using Salesforce CLI. The version control system is the source of truth, and there are no patch orgs. But in 1GP Patch versions can only be created in specialized orgs called patch orgs.
😒 There a highlighted limitation still in 2GP, i.e. Push Upgrades still not possible for 2GP. This feature will be available in near future.
Despite these distinctions, 1GP and 2GP managed packages have many things in common. They share the key packaging concept of associating metadata with a package. And they both allow you to iterate and create package and patch versions, which can be installed and uninstalled in subscriber orgs. Both managed package types enable you to submit a package for AppExchange security review, and list your package on AppExchange. And both managed package types can use the License Management App, Subscriber Support Console, and Feature Management App.
NOTE: In Winter ’20, you can’t submit a 2GP for security review if it contains Visualforce pages or components. This restriction will be removed in a future release.
Comments