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.

Another advantage of committing managed packages to source control is that it’s a quick and easy way of getting managed packages in multiple environments, as 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.

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?