Packages are designed to take the complexity (or ‘dependency hell’) out of developing, updating and releasing new software features. Salesforce’s 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 Gearset, we help teams who use unlocked packages get the most out of streamlined workflows that work for both devs and admins. Recently, we’ve 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’re made aware of what they’re doing. We might not be able to prevent folks from altering packages directly in production (however much we’d 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 ‘happy 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’ve got the same package installed in multiple environments. Whenever you need to check the status of an org, you’ll be a whole lot quicker if you’ve 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.
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 create, install and test your package versions. You add or change your metadata before pushing it to a Dev Hub, which creates the package. Then, once you’ve tested the package and you’re happy, you install that package from the Dev Hub into your org - via your release management process. Your Dev Hub acts at the ‘owner’ 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’s been installed into production. Anyone on your team who can make changes to your production org’s 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’s 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’t lose the hotfix in production when you update the package. Otherwise, any changes made to a package’s metadata will be overwritten if you later reinstall or update the package.
What Gearset does to help
If you delete or change components that are part of a package, Gearset’s problem analyzer gets triggered. Gearset will recommend that you don’t deploy these changes or deletions because they will get overwritten when your team makes an update to the package.
Gearset 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 free 30-day trial 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 Adopting Salesforce DX.
