All Collections
FAQ
Comparisons and deployments
Should I source control managed packages?
Should I source control managed packages?

Decide whether to deploy metadata associated with managed packages into version control

Ali Daw avatar
Written by Ali Daw
Updated over a week ago

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:

  1. Install the new managed package in a development or feature sandbox org.

  2. Using Gearset, compare that org with your source control system (GitHub or Bitbucket etc.) and deploy the Installed Package to a branch.

  3. Deploy the Installed Package onwards 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 Package type 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 Package and 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. 

Did this answer your question?