Managed packages behave differently to most other metadata. It’s usually not required to include managed packages in your deployments, or to manage them in source control, but it can be a good practice for maintaining effective collaboration and consistency across environments.
Committing managed packages to source control is a quick and easy way of getting managed packages in multiple environments; rather than having to manually install the managed package in each org, you can simply deploy the Installed Package metadata, which can be automated using continuous integration.
For example, you could:
Install the new managed package in a development or feature sandbox org.
Using Gearset, compare that org with your source control system (GitHub or Bitbucket etc.) and deploy the
Installed Packageto a branch.Deploy the
Installed Packageonwards from source control to all your target orgs (staging and production etc.). You could use the continuous integration feature of Gearset to do this automatically.
Having the version of a managed package you're currently using explicitly defined in your source control repository is also really valuable. It makes it harder for a different version to get inadvertently installed in other environments - different versions can have different behavior and therefore become a source of bugs. Also, you can handle upgrades to your managed package version as you would any other metadata change: capture the version change in your source-controlled InstalledPackage metadata then deploy this out to your other environments.
When working with a particular managed package, you'll need to make sure that the metadata filter Installed Package is set to All. Alternatively, you can set it to Named Items, but you'll need to manually add the package name.
You may need to edit the Installed Package metadata in your source control system to add a <password>appinstallpassword</password> line before you can install it in other downstream orgs. You’ll be able to find out this password from your package provider.
Some packages require additional configuration after installation that can only be done manually in the target org. You can still use Gearset to install them, and then complete the configuration in Salesforce.
Which managed package metadata to track in source control
If the package is not being modified beyond the original install:
Only the
Installed Packagetype needs to be added to version control. This is because the installed package effectively provides everything an org needs to ensure that managed packages are in sync between source and target.
If modifications are being made to the package:
Both the
Installed Packageand the modified metadata must be added to version control to allow the team to track changes. Given the number of changes associated with managed packages, it is advisable to treat them as distinct features, tracked in their own branches. This will help teams spot changes being made through package upgrades versus other feature development work.
You can find more information about getting started with version control for Salesforce in Gearset's whitepaper.