Test, Build, and Release the Package Development Model

By in
422
Test, Build, and Release the Package Development Model

With the package development model, testing, building, and releasing are done differently than they are with the present application lifecycle.

You move org changes (deltas) between development and test environments if you’re currently using the change set development paradigm until those changes are made available to your production org. The production org is ultimately the “source of truth.” You can be sure that everything is in your organization even if you use a version control system to track changes that are made externally.

However, you now have choices! Your version control system is the new and enhanced source of truth in the package development approach. Your source is organized into package directories using Salesforce DX projects. Your ultimate objective is to provide versions of those directories that are simple to update, install, and upgrade.

Throughout the entire process of developing a package, Salesforce CLI can be used.

Package Development Model Test

 

Push your metadata onto a different scratch org allocated for that reason when you’re prepared to do manual or exploratory testing of your development effort (1). Since it is solely used for testing and validation, you never retrieve anything from that organization.

The goal of continuous integration (CI) is to automatically run reliable tests against each batch of changes that are merged into your application (2). Before any faulty modification can enter your source repository, this crucial process guarantees the quality of your program.

It is simple to incorporate Scratch orgs into a CI workflow. Scratch orgs can be scripted into a CI flow because the CLI can construct them. You can run tests on the particular update after adding the correct version of the source repository to the organization.

Scratch orgs, as opposed to developer sandboxes, allow for continual creation rather than a single refresh each day. When the need arises, you can simply build a new scratch org by deleting the previous one. You can have several scratch orgs, each serving a particular function. You have a ton of freedom with little overhead with Scratch orgs.

 

Conclusion

In this way, when using the package development model, you can make a package version when you’re prepared for release testing or continuous delivery automation. You create and install package versions (3) in every testing environment as opposed to using change sets to transfer changes between them. You install a package version in your production org after testing is over.

 

Additional Resources

Cover Photo by Ivan Henao on Unsplash

Leave a reply

Your email address will not be published. Required fields are marked *