Business Automation using Microsoft Power Platforms
Fintech
Binding seamless Technology with Finance
General Published on: Fri Feb 10 2023
So far, nothing has broken since you’ve been building managed package apps on the platform with joy. However, with the advent of Second-Generation Packaging, upgrading is no longer as straightforward. You’ve come to the right place.
You can use 2GP (Second Generation Packaging) to organize your source, build small modular packages, integrate with your version control system, and better utilize your custom Apex code. There are no packaging or patch orgs because version control is the only reliable source of information. All packaging tasks can be carried out via the Salesforce CLI or automatically with scripts. List second-generation managed packages on AppExchange after submitting them for security evaluation. Let’s dive into the 2GP-specific benefits and then why.
Feature of 2GP over 1GP:
2GP Vs 1GP
Or See Comparison of 2GP and 1GP Managed Packages for more details.
Limitations in Second Generation Packages in Salesforce
Salesforce will continue to invest in 2GP, which has distinct advantages over 1GP and is the technology for app development. However, as the most recent packaging technology, 2GP still needs to catch up to 1GP in terms of feature parity. Current gaps are:
We hope this gives you the confidence to study more and utilize 2GP.
Pre-requisites for creating 2GP Packages:
Note: – The proper permissions must be set in the Dev Hub org for developers working with 2GP packages. Either the Create and Update Second-Generation Packages permission or the System Administrator profile is required for developers. Add Salesforce DX Users for further details.
Workflow for Second-Generation Packages
So, now we are all set to get some hands-on 2GP.
Create SFDX Project and Auth DevHub
To get started, you will need to create a new directory on your Dev machine.
Include the —-setdefaultdevhubusername option while carrying out this step. After that, when executing additional Salesforce CLI tasks, you can omit the Dev Hub username.
Create Scratch Org (Dev Edition can also work)
Check sure every component of the package is present in the project directory where you wish to create it. You must add at least one piece of metadata before moving on to the next phase if you are testing out the exact steps and commands in this workflow.
Push code to Scratch Org
Run the command: From the Salesforce DX project directory,
Create the Package
For each package, the following command only has to be run once. Even though we claim that customers install packages the majority of the time, they really install versions.
One more Dev Edition/Sandbox/Scratch Org, for installs.
You may already have a Dev edition org that you can use to install the package we’re experimenting with. If not, you’ll need to create one. Avoid doing this in Production… As a precaution. You’ve been forewarned.
Review your sfdx-project.json file. The CLI generates an alias using the package name and automatically modifies the project file to include the package directory.
Notice the placeholder values for versionName and versionNumber. You can update these values or indicate the base packages that this package depends on. Your generated namespace will be visible in your project file.
Create a package version
The package metadata is presumed to be in the force-app directory in this example.
There are two ways we can create a version for a package that is
(1) Without —codecoverage (See (2) in the above image) –
CLI does not check the codecoverage but the problem with this is that the package cannot be promoted from Beta to Released package. And demonstrate this kind of error –
(2) With –codecoverage (See (1) in the above image) –
CLI will test all the test classes for more than 75% code coverage if all went well then it starts making the package.
When this command is done, you’ll see something like this on the Terminal:
If you have included all the components and dependent components correctly then you can move to the next step but if there is an error, try to resolve the error by including the required component.
But before you go to the next step, In the 2GP package we don’t have the right to include some metadata types. E.g., we cannot include AuthProvider in our package. If we include, then this error is shown –
For more details – https://developer.salesforce.com/docs/metadata-coverage
Install the package version and test it in a scratch org.
Promote package to a released state-
To make your package available for the Production org, we need to promote it to the released state or other than the Beta version.
Promote package to a released state-
To make your package available for the Production org, we need to promote it to the released state or other than the Beta version.
After clicking Enter, you will receive the below message
After clicking y –
After this, you can install your package as you did in the above step with the URL.
So that all in the Package creation and installation. Now you can play around with packaging.
Best Practices for Second-Generation Packages
When working with second-generation packages, we advise that you adhere to these best practices.
Different Types of Packages in Second-Generation Package
Get 30 Mins Free
Personalized Consultancy