what are the change set limitations in Salesforce?

Hello Uday,

ChangeSets is one of the primary tools that Salesforce provides for developers and administrators for the migration or deployment purposes. For an Enterprise Application System such as Salesforce, customers, partners, and the development community rely on a comprehensive and enterprise-grade set of tools to deliver innovation and releases rapidly and successfully. Here are eleven reasons why customers are looking for alternative deployment solutions to ChangeSets.

Deploy all the metadata components in one shot: With Salesforce ChangeSets, you cannot deploy all the types of metadata components in one shot. For example, if you are deploying custom settings and a Visualforce page which leverages those custom settings, you cannot deploy all those components at once. You would first need to deploy custom settings, and then create a Changeset for deploying Visualforce page.

Merge code with other developers: Salesforce recommends that each developer work in their own developer organization. However, if developers need to merge code from various organizations into a single deployment unit, it is not feasible by using Salesforce ChangeSets.

Use the same ChangeSets across your delivery chain: Developers need to create Salesforce ChangeSets over and over again. For example, if a developer needs to deploy the code from Dev to QA to UAT organizations, they would have to create the ChangeSets twice to move across these two organizations.

Perform partial deployment: Salesforce ChangeSets either deploy all the components or rollback all the components on any failure. There is no way to deploy successful components and ignore the failed components.

Deploy all types of metadata components: Salesforce ChangeSets do not support all types of metadata components. If you need to deploy certain types of metadata components, you would have to deploy them manually or by using an IDE such as Eclipse.

Integrate with version control: It’s not feasible to integrate Salesforce ChangeSets with any version control system.

Stop overwriting changes from other developers: Because metadata components are not versioned, developers often overwrite each other’s changes. For example, a developer can deploy the latest version of a component. Subsequently, another developer can redeploy the “older version” of the component which was not changed.

Quickly deploy: For any deployment, you need to upload ChangeSets and deploy them to the target organization. This greatly increases the deployment time.

Governance across the delivery chain: With Salesforce ChangeSets, there is absolutely no governance. Any developer can make any modification to another organization if they have permissions to make changes to it. The auditor cannot track who made the changes to the organization.

Impact analysis before deployment: Salesforce ChangeSets have a functionality of dependency. However, this functionality is not clearly useful. Ideally, the functionality should perform an impact analysis against the target organization and suggest the dependencies that should be automatically included.

Maintain Sarbanes-Oxley compliance: One of the requirements for Sarbanes-Oxley is that IT organizations must maintain a complete change control over the infrastructure. With ChangeSets, there is no central place to track the changes made to an organization.