Deploying changes with packages
Packages are like change sets but without the constraint that states that organizations should all be children of the same production organization.
This means that change sets are not available on Developer Edition organizations, whereas packages are, and that we can only deploy metadata that is isolated from the destination organization’s configuration (packages can be used by ISVs to provide AppExchange general porpoise apps, that’s why a package can’t be aware of what’s already on your organization).
For more information about the ISV partner program, take a look at Trailhead at https://trailhead.salesforce.com/content/learn/trails/isv_developer_beginner. Packages can also be used to release basic libraries of metadata (such as common formulas, Apex classes, and validation rules) that consultants commonly use on their projects.
To create a new package, click on Setup | Apps | Package Manager. Skip the Developer Settings part. This is used to set up the Namespace prefix, which is used to isolate your components from another organization’s components in order to avoid naming conflicts (this is needed when you’re building managed packages, which are special kinds of protected packages that are required for AppExchange publication).
Click on the New button and give the package a name and description. Then, click on the Add button to add components:
Package editing
The cool thing about packages is that Salesforce automatically adds all the related components to the package. In this example, we have just selected the workflow rules, but we can see that the engine added two field updates and a custom field.
Why do change sets differ in this way? In change sets, you are deploying from a sandbox to sandbox/production organizations, so there is a chance that some components may already be on the destination organization. On the other hand, with packages, we must ensure that everything we need is packed up and ready to be installed anywhere.
When uploading a package, we can define a version name and number (so it’s easy to spot which version has been installed in a given organization), as well as an optional password for installation protection (only those who own the password can install this package), a site URL for release notes, post-installation instructions (if any), and features and object requirements.
You can add profiles or permission sets to make the administrator’s life easier (only installed components will be affected on the destination organization), just like we can on change sets.
After a successful upload, you’ll be granted an installation URL that anyone can use to install this package on any organization.
For a complete guide on package management, please refer to Salesforce Help at https://help.salesforce.com/articleView?id=package_distribute_apps_overview.htm&type=5.