#Second Generation Packages0 discussing

Hi all!

I want to share with you the article about Second-Generation packages in Salesforce from my SF Dev colleague.  He collected all the features and the main differences between 1GP and 2GP there. It's just a personal experience, so maybe you will find it useful. 

#Salesforce Developer #Package Installation #Second Generation Packages 

Hello Guys,

I am new to Second Generation Packages and trying to get some guidance from experts who have already worked on it before. 

I have a quick question on the best practices for managing the Parter Business Org when developing Second Generation Packages. As Parter Business Org act as the Dev Hub for the second generation packaging and the dev hub owns the packages (which can not be changed once the package is generated), what is the best practice on handling CI/CD process. Before we deploy the final package to production which will be on Parter Business Org Dev Hub org, we need to build and test the packages many times as beta features in a CI org. We many times need to have many CI processes which will have the same package names. These are just beta packages and we don't want to deploy these to the Parter Business Org yet.

So what is the best practices being followed for this? Do you guys use the same Parter Business Org for all these purposes (I hope this is not the case) or you guys request new org with dev hub for incorporating CI/CD purposes.

I would like to get some suggestion on what is the best practices being followed in this.

Thanks,

Bikram.

Question about best practice for SFDX package versioning with automated builds and deployments:

At present we use git workflow which consists of a master, uat and develop branch. Each branch triggers a build following a successful pull request. When the build runs for the develop branch, it validates the dx project by creating a new scratch org and pushing metadata etc. Following this, it creates a new package version of the metadata and then kicks off a deployment. The deployment installs the new package version into a developer sandbox, along with its dependent packages (using a custom script).

I am now facing a challenge with configuring the build and deployment for the uat branch. The deployment this time will install the package and dependent packages into a shared environment which is used for the UAT of all apps we have. The problem and confusion I have run into is around how I version the package following the successful build of the uat branch. Commits that are pushed into the uat branch are always behind develop , as you may expect. So I really don't want to be creating a new package version for the uat build which is likely to be behind develop.

I have thought of two alternative approaches here

1. When building from the uat  branch, increment the major or minor version of the package (the develop branch would then need modifying to increment the version there too).
2. Rather than creating a new package version for each build of develop, only create a new package version for the uat  build. (I'm less in favour of this as we would then need to deploy the metadata rather than installing a new package version into the dev sandbox)

Does anyone have any ideas as to how I best go about this?

Hi,

I am unsure if I have the dependencies working for my package. After creating two packages I expected a package with any dependencies would automatically install those dependencies.

Instead I got this error message:

$ sfdx force:package:install -i 04t0N000000LFFdQAO -u EmptyOrg1

...

$ sfdx force:package:install:get -i 0Hf0E0000008STCSA2 -u test-few5zg80loix@nelson_company.net

ERROR:  Encountered errors installing the package!,Installation errors:

1) Variable does not exist: CoreController, Details: FeatureOneController: Variable does not exist: CoreController

I have the following folder structure 

├── README.md

├── config

│   └── project-scratch-def.json

├── core

│   └── main

│       └── default

│           ├── aura

│           └── classes

│               ├── CoreController.cls

│               └── CoreController.cls-meta.xml

├── feature-one

│   └── main

│       └── default

│           ├── aura

│           └── classes

│               ├── FeatureOneController.cls

│               └── FeatureOneController.cls-meta.xml

└── sfdx-project.json

The sfdx-project.json file looks like this:

{

"packageDirectories": [

{

"path": "core",

"default": true,

"id" : "0Ho0N0000004C9XSAU",

"versionNumber" : "0.0.0.NEXT",

"versionDescription" : "Core 0.0.0.1",

"versionName": "Core1V0.0.0.1"

},

{

"path": "feature-one",

"id" : "0Ho0N0000004C9cSAE",

"versionNumber" : "0.0.0.NEXT",

"versionDescription" : "Feature One 0.0.0.2 this package has the dependency on core",

"versionName": "Feat1V0.0.0.2",

"dependencies": [

{

"packageId": "0Ho0N0000004C9XSAU",

"versionNumber": "0.0.0.LATEST"

}

]

}

],

"namespace": "HelloDemo01",

"sfdcLoginUrl": "https://login.salesforce.com",

"sourceApiVersion": "41.0"

}

That original json file will build the packages I want but I need to install my core package if I want feature-one to install. Dependencies aren't installed automatically, is that not expected?

I also tried changing my dependencies to list the subscriber id like this (https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_dev2gp_config_dependencies.htm)

"dependencies": ["04t0N000000L8AQQA0"]

I get this error when I try and rebuild the package:

$ sfdx force:package2:version:create -i 0Ho0N0000004C9cSAE

ERROR:  Dependency must specify either a subscriberPackageVersionId or both packageId and versionNumber: "04t0N000000L8AQQA0".

Thanks

Nelson