What are the advantages,disadvantages of Changesets ,Force.com IDE(Eclipse)

Question

Can any one help me out with the advantages,disadvantages of Changesets ,Force.com IDE(Eclipse),Migration tool.

Which tool is preferred.

Correct me if im wrong

Changes Sets :Track the history,profiles can be moved.

Eclipse :profiles,premission sets cannot be moved,Any changes done in sandox is updated in production whereas in changeset we need to select nd move in to production.

Any help very much appreciated.

Answer 1

There are two big categories for moving changes between Salesforce orgs

1. Change sets
2. Metadata API (Eclipse IDE, Migration Tool, 3rd parties)

Change sets

• Pro: Provide a nice native UI for picking changes that need to be moved between orgs.
• Pro: When you move that change it gives you a decent representation of code coverage and progress.
• Pro: Provides a nice audit trail and shows what changes were deployed when
• Con: Can be fiddly to select all the changes you want to bring across
• Con: Can be hard to get the granularity on things you deploy (only parts of profiles for example)
• Con: Can't be part of an automated deployment so governance around change management can be a tricky and manual process
• Con: Hard to have as part of development flow with the need to recreate the changeset every time you want to move the change to another org (e.g. dev -> QA -> UAT -> Prod)
• Con: Only works with connected orgs, so you need to establish a trust relationship between orgs that can make experimentation more tricky.
• Con: Doesn't allow for destructive changes (deleting objects)

Metadata API (e.g Eclipse, Migration tool, 3rd parties)

• Pro: Way more power so you can manipulate the actual files
• Pro: Can be part of an automated process
• Con: Variable usability depending on which tool you use
• Con: Often fails due to missing dependency analysis

Those are the two built-in options. Full disclosure that I lead the team, but at https://gearset.com we are building a solution that is better than the other options. We aren't quite there yet but we are making good progress and some senior guys in the community, such as Matt Lacey (http://www.laceysnr.com/2015/04/introducing-gearset-simplifying.html), have had good things to say about us.

For a 2 minute video showing what we offer, check out https://gearset.com/blog/migrating-salesforce-changes-with-gearset-deploy.

Answer 2

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.

Answer 3

You are correct about Change sets - Track History. And more over only the selection procedure in Change sets are a bit complicated especially if you are trying to move an object & its fields but the movement and code coverage UI for Change sets are much better than earlier. So I would suggest Change sets as it even tracks history and we need not to keep a check on the recent updates.