12

Recently we've been developing an unmanaged package to bundle all our ongoing client metadata in one unit. This is useful when attempting to move stuff between sandboxes before the package goes to production itself.

Different groups of users may want to see the same set of features in different sandboxes. Such as Development, UAT, Training and so on.

My intention was then to deploy this package into production, when ready.

However, Salesforce documentation says

Unmanaged packages should not be used to migrate components from a sandbox to production organization. Instead, use Change Sets.

If we use changesets then we need to remember all the metadata that has been developed. There's no way to bundle changesets. The opportunity for human error is clear.

So why does Salesforce advise against using unmanaged packages as a deployment strategy to production?

Improve this question

2 Answers 2

Reset to default
10

Having unmanaged package installation approach in production you can't

  • Uninstall the package if it is being referenced by component which is not part of that package
  • You can not upgrade unmanaged packages. You will have to uninstall the previous one.
  • You cannot overwrite a component which has same API name in production but not part of the package and package also contains the component with same API name.
  • In production you don't have enough development controls to resolve the dependencies issues. If package start causing issues you will stuck due to lack of controls.

With changesets above issues don't occurs. Also you can build a single unit of changeset and upgrade it by cloning and adding components.

Packages are good for distribution purpose.

Improve this answer
2
  • Some good points, thanks. I'm not sure what your last point means. "you don't have enough development controls". Can you expand your answer?
    – powlo
    Commented Aug 17, 2015 at 15:00
  • Honestly, number 3 on your list sounds like a good reason for using a package. The client might not want their components overwritten and it would be good to have a warning message about the naming conflict before the deployment/install.
    – martin
    Commented Aug 17, 2015 at 16:59
3

Four years later, Salesforce DX and Unlocked Packages have reversed the answer given above. Now Salesforce is recommending that application development takes place in Unlocked Packages and that these can be installed in Production or a Sandbox for many of the reasons that the original post mentions. Existing applications should be rebuilt as Unlocked Packages as well to reduce Org Complexity. Deploying everything with unpackaged assets is no longer the Best Practice for Release Management.

https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_unlocked_pkg_intro.htm?search_text=unlocked

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .