Package development model

In package development, you manage different customization as separate packages, not as one big release of changes to the org.

Continuous integration and delivery is used in conjunction with version control to automate promotion of functionality into higher environments.

The source control server has a monitor that checks for changes and automatically moves them to an integration sandbox.

When you’re working in a package development model, you build a release artifact you can test and release independently from artifacts for other projects.

A package is a release artifact that is a group of related source and metadata. The metadata in the package includes both changed and unchanged components.

A package version is a fixed snapshot of the package contents and related metadata.

The package version lets you manage what’s different each time you release or deploy a specific set of changes added to a package. If you’re introducing metadata changes to an already deployed package, you upgrade from the current package version to the newer package version.

Scratch orgs play a key role in significantly reducing the changes dev team need to track for each release.

Scratch orgs are empty orgs (no metadata or data) that are easy to create and dispose of as needed. You can configure scratch orgs to be different Salesforce editions with different features and preferences. What’s more, you can re-use and share the scratch org definition file with other team members, because it’s part of the project integrated into the VCS.

When you use scratch orgs for development, you first push the source from your project in the VCS to sync the scratch org with the same metadata.

You can pull down the modifications you made in your Scratch org to include them in your project and use your VCS to commit all the changes.

Before you commit to your version control system, be sure to run tests. You can either use the same scratch org to run tests, or spin up another specifically for testing before you commit your source.

Create a Package and Package Version

Steps:

In the command window, let’s make sure that the Dev Hub org is connected.

sfdx force:org:list

Check the sfdx-project.json;

{ "packageDirectories": [ { "path": "force-app", "default": true } ], "namespace": "", "sfdcLoginUrl": "https://login.salesforce.com", "sourceApiVersion": "44.0" }

Create an unlocked package without a namespace, and supply the alias or username for your Dev Hub org if it’s not already set as the default:

sfdx force:package:create --name dreamhouse --description "My Package" --packagetype Unlocked --path force-app --nonamespace --targetdevhubusername DevHub

Create a Scratch Org to Test Your Package Version

sfdx force:org:create --definitionfile config/project-scratch-def.json --durationdays 30 --setalias MyScratchOrg -v DevHub

In sfdx-project.json, Change the versionName to Version 1.0, and the versionNumber to 1.0.0.NEXT.

In the <appname>-sfdx directory, create the package version, which associates the metadata with the package.

sfdx force:package:version:create -p <appname as per sfdx-project.json> -d force-app -k test1234 --wait 10 -v DevHub

Use the package version alias(given in sfdx-project.json) to install the package version in the scratch org that you created earlier.

sfdx force:package:install --wait 10 --publishwait 10 --package dreamhouse@1.0.0-1 -k test1234 -r -u MyScratchOrg

After the package is installed, open the scratch org to view the package.

sfdx force:org:open -u MyScratchOrg

When you’re ready to perform manual or exploratory testing of your development work, push your metadata into a separate scratch org designated for that purpose (1). You never pull anything from that org, as it’s only being used for testing or validation.

Continuous integration (CI) is about automating consistent test runs against every set of changes merged to your application (2). This important process ensures application quality before any corrupt change can get into your source repository.

When you’re ready for release testing or continuous delivery automation, you create a package version. Instead of using change sets to move changes between environments, you create and install package versions (3) in each testing environment. Once you complete testing, you install a package version in your production org.

To learn more - https://trailhead.salesforce.com/content/learn/modules/sfdx_dev_model/sfdx_dev_model_evolve_to_dx?trail_id=sfdx_get_started