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?
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.