Change sets versus packages versus Metadata API
Key Takeaway
Use a change set for point-and-click moves from a sandbox to its production org, an unmanaged package for an app the recipient will customize, and Metadata API for managing customizations through tools.
After you build and test customizations in one Salesforce org, such as a sandbox, you need a way to move them into another org, such as a production org. Change sets, unmanaged packages, and Metadata API can each move customizations, but each one fits a different job. The right choice depends on where the changes are going, who will change them afterward, and whether you work in the Salesforce user interface or through tools.
What a change set can hold
A change set sends customizations from one Salesforce org to another.
For example, you can create and test a new object in a sandbox, then send it to the production org in a change set.
A change set can hold workflows, rules, and Apex classes and triggers, plus other customization, but only changes you can make through the Setup menu. It carries information about the org, not data, so you can't use a change set to upload a list of contact records.
The components you can add to a change set vary by experience and edition. Some components also depend on their corresponding features.
You can carry permissions and other access settings in a change set with permission sets, profile settings, or both. Weigh how the two differ before you decide which to include.