Change sets versus Salesforce CLI versus DevOps Center for a release
Key Takeaway
Use a change set for a point-and-click release that was built in Setup and moves once from a sandbox to production. Use Lifecycle Center when admins and developers need one shared, governed, source-controlled pipeline to production. Salesforce CLI is the command-line tool for developers who write code.
A release moves tested changes from a development environment, such as a sandbox, into production. Salesforce offers several tools for a release. Change sets are for point-and-click deployments in the Salesforce user interface. Salesforce CLI is for command-line and code-based work. Lifecycle Center (formerly DevOps Center) is for governed releases tracked in source control. The right choice depends on who builds the changes and how much governance and traceability the release needs.
Keep production safe
Make and test changes in a dedicated development environment, such as a sandbox or scratch org. Then deploy the complete changes to production. Developing directly in production is risky, because even one small untested change can break a critical process or damage data. Some work, such as writing Apex code, must be done in a development environment.
A release pipeline with several testing stages proves that integrated changes work together. The stages let you practice the deployment. They also expose anything missing from the deployment artifact. Stakeholders can run user acceptance testing in a Partial Copy or Full sandbox.
Not every change needs a deployment tool. Developing email templates, creating or editing users, and creating or editing permission sets and profiles are acceptable to do directly in production. Changing a field's type is different, because it can irreversibly alter data or cause Apex code to recompile.
Limit who can change production. Give "Customize Application" access only to admins. Restrict permissions for programmatic deployments to a small number of admins.