11 Things That You Cannot Do With Salesforce Change Sets, (And Never Will!)
Migrating metadata and configuration changes between environments is a critical and integral part of what Salesforce developers and administrators do. During the development cycle, developers migrate changes many times, either to keep development organizations in sync or to move changes from development organizations toward production.
Change sets 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 Salesforce Change sets and how you can overcome.
#1 Deploy all the metadata components in one shot
With Salesforce Change sets, 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 Change set for deploying Visualforce page.
#2 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 Change sets.
#3 Use the same Change Sets across your delivery chain
Developers need to create Salesforce Change sets 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 Change sets twice to move across these two organizations.
#4 Perform partial deployment
Salesforce Change sets 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.
#5 Deploy all types of metadata components
Salesforce Change sets 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.
#6 Integrate with version control
It’s not feasible to integrate Salesforce Change sets with any version control system.
#7 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.
#8 Quickly deploy
For any deployment, you need to upload Change sets and deploy them to the target organization. This greatly increases the deployment time.
#9 Governance across the delivery chain
With Salesforce Change sets, 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.
#10 Impact analysis before deployment
Salesforce Change sets 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.
#11 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 Change sets, there is no central place to track the changes made to an organization.
Overcome the limitations of Change sets with Flosum. A Powerful release management solution for Salesforce, on Salesforce, Flosum is better than Salesforce Change sets.
