Discover the Managed 2GP Package Development Workflow
Learning Objectives
After completing this unit, you’ll be able to:
- List the steps in the package development workflow.
- List the package development steps that could be automated in a continuous integration script.
- Describe a beta version of a package.
Key Aspects in Managed 2GP Package Development
In this unit we highlight some key aspects in the managed 2GP package development workflow. Our goal is for you to understand the managed 2GP workflow. We won’t ask you to follow along and create a package.
If you want a more detailed workflow, including the CLI command for each step, see Workflow for Second-Generation Packages in the Second-Generation Managed Packaging Developer Guide.
Step 1: Create a Salesforce DX Project
Using Salesforce CLI, create a Salesforce DX project. Set up a repository in your source control system to manage the metadata for your app.
Step 2: Develop Your App
Create a scratch org, and use the scratch org to develop the app you want to package. Salesforce Extensions for VS Code is a great tool that makes your package development easier.
After you’ve added all the metadata components your package requires, verify that each component is in the project directory where you want to create the package.
Step 3: Configure and Create Your Package
Specify your package’s namespace in the sfdx-project.json file, and review the project file to ensure it includes the settings and any dependencies your package requires.
Create a scratch org definition file, or an external .json file, that specifies the features and org settings required for the metadata in your package.
Then from your local Salesforce DX project directory, create the package using the sf package create Salesforce CLI command. Only run this command once for each package you create. This CLI command is run against your Dev Hub org, and your Dev Hub org becomes the owner of the packages you create.
Step 4: Create a Package Version
From your project directory, create a package version using the sf package version create Salesforce CLI command.
When you create a package version, you take a snapshot of your package metadata to create an immutable, installable artifact. As you iterate on your package, you come back to this step and create new package versions.
Step 5: Install and Test the Package Version in a Scratch Org
Create a new scratch org to test out your package. You need a new scratch org for this step. Don’t reuse the scratch org that you used to develop your package in step two.
Install your package into the new clean scratch org using the sf package install CLI command, and then open the scratch org and view your app.
Step 6: Promote and Release the Package Version
A package version is, by default, a beta version until you promote it. Beta versions can’t be installed in a production org. This safeguard ensures that the package version you release is production ready.
When a package version is ready for the world, you promote the package version to released using the sf package version promote command.
To promote a package version to released, the Apex code must meet a minimum 75% code coverage requirement, and every Apex Trigger in a package needs test coverage.
Automate Package Development Steps
Write continuous integration (CI) scripts to automate these package development steps. For example, you could write a script that creates a package version, creates a scratch org, installs the package version in the scratch org, runs Apex tests, and emails the test results to the release manager.
The journey from idea to app on AppExchange doesn’t end with package development. Check out these resources on how to get your package security-reviewed, and how to publish it on AppExchange. In the next unit we look at the subscriber experience of packaging.
