CodeScience tech webinars offer useful developer tips and tricks from members of our industry-leading engineering teams. In our latest tech webinar, Krishna Tatta, CodeScience Director of Technology, looks at the benefits and known issues of Second Generation Packaging (2GP), along with how ISVs can leverage it to better manage and distribute their app to Salesforce customers.
Krishna starts out by describing exactly what 2GP is: a new way for ISVs to develop, manage, and distribute their apps and metadata. She notes that it’s particularly well-suited to — and fundamentally based on — a modular development approach, which emphasizes the separation of various functionalities of your solution into smaller, independent, more efficient pieces so you can develop them more quickly. 2GP supports this modular approach by “encouraging multiple, interoperable packages instead of one big, bulk package,” Krishna explains. She notes that 2GP also provides for tighter integration with source control and allows for automation of all packaging operations through command line interface (CLI) commands.
How does 2GP work?
Having clarified exactly what 2GP is, Krishna provides a step-by-step overview of the process required to create a second generation package, from enabling the Dev Hub and linking the namespace(s), to creating, installing and testing the package, and ultimately promoting the managed release version.
“This is a repetitive cycle. As you’re iterating on your product, you’ll be creating new package versions,” Krishna explains, adding that all of this is done through CLI. Krishna then walks us through a comprehensive demo of each step of the 2GP process (you’ll need to register here to see the demo in action).
Differences between First and Second Generation Packaging
So, what are the main differences between 1GP and 2GP? One key differentiator Krishna highlights is that each approach handles the namespace differently. With 1GP, one namespace equals one package, but with 2GP, you can have multiple packages using the same namespace. “This is going to be very helpful, especially if your package landscape has a lot of interdependency,” Krishna explains. “If you have multiple packages that need to communicate with each other, having them all in the same namespace is huge.”
Another difference between 1GP and 2GP has to do with versioning. Versioning in 1GP is strictly linear, so there is no ability to branch. With 2GP, “you can have a very complex hierarchy if needed, but be very careful,” Krishna warns. Developers must take into consideration their release management and governance processes to maintain control over this complexity, “however, it gives a lot of flexibility on which package version you choose as an ancestor for each new version that you’re creating.”
Is 2GP the right choice for you?
Krishna concludes the webinar by reviewing all of the known issues of 2GP as well as offering advice on how to decide which approach is right for you. There is not yet complete feature parity between 1GP and 2GP and while this results in quite a few technical gaps, there are workarounds for some, and a few others that may or may not be relevant to your product. Of course, Krishna advises, the Salesforce packaging team is working hard to address these issues; they are clearly focusing their efforts on 2GP over 1GP and prioritizing 2GP features. “Salesforce invests in the future,” she notes.
As for choosing which approach is best for you, it really depends on what stage of development your product is in and whether or not the known issues will impact your product. Krishna provides a few different paths forward depending on use case and adds, “if you’re not sure, depending on your use case, if these gaps apply or not, or if you want to dive deeper into any of the concerns that are shared here and a few more, please reach out to us at CodeScience!”