Packages are designed to take the complexity (or 鈥榙ependency hell鈥�) out of developing, updating and releasing new software features. Salesforce鈥檚 unlocked packages, also referred to as second-generation packaging (2GP), make it possible for teams to develop and deploy self-contained units of code. As part of Salesforce DX, unlocked packages support a modern, modular and iterative development process on the platform.
At 海角天涯社区, we help teams who use unlocked packages get the most out of streamlined workflows that work for both devs and admins. Recently, we鈥檝e added some useful alerts to our metadata deployment and continuous integration processes. Whenever a user attempts to deploy changes to components within an unlocked package, we make sure they鈥檙e made aware of what they鈥檙e doing. We might not be able to prevent folks from altering packages directly in production (however much we鈥檇 like to sometimes 馃槈), but at least we can alert you when they do. That way, you can prevent changes made in your production org from being overwritten when the packages get updated later on.
What are unlocked packages and why do teams use them?
Much like the managed packages that you install from the AppExchange, unlocked packages are separate bundles of metadata that make up particular custom features and functions that you add to your orgs. Working with smaller unlocked packages containing a subset of your metadata has several benefits over working with complete orgs containing all of your metadata in a 鈥榟appy soup鈥� or Salesforce potpourri.
Package versions are key to any software packaging. Introducing new features as separate packages and releasing changes as new versions helps you follow an iterative development process. For example, you can often install, upgrade and fix bugs more easily and more quickly with versioned packages - especially if you鈥檝e got the same package installed in multiple environments. Whenever you need to check the status of an org, you鈥檒l be a whole lot quicker if you鈥檝e only got to check the version numbers of your packages than if you have to examine unmanaged metadata. And, more than anything else, the dependency risks associated with deploying a new feature are much lower if the feature is held in a largely self-contained package.
Salesforce DevOps in the age of AI: is your custom pipeline ready?
Working with packages and source control
Package-based development works hand in hand with source control. You create and manage your packages as Salesforce DX projects within Git branches. Using the Salesforce CLI, you can perform all of your packaging operations to . You add or change your metadata before pushing it to a Dev Hub, which creates the package. Then, once you鈥檝e tested the package and you鈥檙e happy, you install that package from the Dev Hub into your org - via your release management process. Your Dev Hub acts at the 鈥榦wner鈥� of your package, while your version control system remains the source of truth for the metadata contained in the package.
As the name suggests, an unlocked package can be modified after it鈥檚 been installed into production. Anyone on your team who can make changes to your production org鈥檚 metadata will also be able to make changes to the metadata inside the unlocked package. Hotfixes made straight into production are a common example of this. But here鈥檚 the important bit: after spotting and fixing a bug directly in your org, you need to bring the hotfix back into Git to create a new version of the package. This way, you won鈥檛 lose the hotfix in production when you update the package. Otherwise, any changes made to a package鈥檚 metadata will be overwritten if you later reinstall or update the package.
What 海角天涯社区 does to help
If you delete or change components that are part of a package, 海角天涯社区鈥檚 problem analyzer gets triggered. 海角天涯社区 will recommend that you don鈥檛 deploy these changes or deletions because they will get overwritten when your team makes an update to the package.
海角天涯社区 also helps you detect any changes made to packages in production early on. If you are running a change monitoring job for your org, any changes made to components inside an unlocked package are shown on the monitoring history page. Changes made to unlocked packages show up under the Packages affected column.
Questions about unlocked packages?
Already using unlocked packages but looking for a solution to make deployments even easier? Start a now, with nothing to install in your orgs.
For a detailed overview of source-driven processes for Salesforce and advice on starting out with Salesforce DX for DevOps, see our whitepaper on .
