Using Change sets Effectively For Enterprise Application Deployment For Force.com Projects

Deployments in force.com can be a headache specially if you are new to platform ,in fact you may mess up if you use changesets and have no experience before doing this or if you have come up from java/.NET background where you have used ANT for deployments and now asked to use change sets of salesforce

The aim of this blog-post is share some of the tips and tricks for using the changeset effectively for deployment.

So i assume here that we generally go through salesforce document and we are ready after going through salesforce document to explore some tips and tricks that i generally use for deployments when using change set

http://help.salesforce.com/HTViewHelpDoc?id=changesets.htm&language=en_US
https://help.salesforce.com/apex/HTViewHelpDoc?id=changesets_best_practices.htm&language=en

The above links is must read before you start reading the tips i have for using changesets effectively

Problem 1:The field level security and permissions of objects and fields are not obeyed once i deploy fields and objects using changesets 

http://salesforce.stackexchange.com/questions/15238/change-sets-including-custom-objects-and-custom-fields

So the solution is quite simple we forget that profiles and permission sets should be migrated along with migration of fields,objects,apex classes,visualforce,record types etc to apply the permissions 

Problem 2:Reports and Dashboards don't migrate properly

Reports and Dashboards do get migrated well with changesets .All that we need to ensure is to include the folders also that are necessary along with these dashboards .

There are two specific problems that i encountered 

i)In deploying folders or dashboard we get error saying the user with given mail ID don't exist in destination org 

Solution is simple, either we will have to remove the running user from the dashboard of  current org from which we are deploying or other way around to temporarily form  the user mail id in the destination org or may be create folders not deploying manually

ii)I received internal sever error when migrating reports and dashboards .

Internal server errors are meant for salesforce support but here is something that comes by luck sometimes

 If the destination organisation does not have folder sharing enabled then we cant deploy reports we receive internal salesforce errors.Manually enable in destination org to resolve this issue 

Problem 3:Deployed email templates in one go and in next go i deployed letter head and there was no association between email template and letter head 

This particular thing i noticed and looks like a bug but nevertheless,we must be careful in deploying email templates and letterheads .Its better to include both together to avoid such complains .

Problem 4:Its difficult adding fields to changesets when i have large number of fields or components 

For this lets hack a salesforce a bit .

So from the above pictures we will need to follow these to make our life simpler .First we will sort the fields by Type and then click on the "more" link found at the bottom.

Now the fields looks little better organised for the selection.Lets make it more easier .

si=-2&lsr=0&entityType=CustomFieldDefinition&rowsperpage=260

So observing the url once we click more, at the end of the URL we find a parameter called rowsperpage.This parameter holds no of rows that is displayed when forming the changesets .Now if we increase the rows per page from 260 to some large number 50000 we find we avoided pagination and now sorting on type again ,we find the interface is really selective and we need not paginate lot to add components into changeset.

si=-2&lsr=0&entityType=CustomFieldDefinition&rowsperpage=50000

Increasing rowsperpage avoids pagination and we can scroll at bottom to greater extent and avoids us to one more iteration to add components into changesets 

Disadvantages of Changesets 

Some of the disadvantages of changesets are as follows which needs some attention in future from salesforce

1)For standard fields and objects we will need to manually check permissions and field level security(manual activity or use force.com IDE)

2)Removing components from changeset is painful..yes its painful due to bad user interface and with no sorter available and pagination rendering is ajax one making more slower

Few Interesting tips 

1)The components in changesets are the very latest version components at that particular instance in the organisation.What i meant by this is say you formed a changeset at an hour before and one of the trigger got deactivated later ,say 10 minutes before you deployed into next instance .The trigger will appear deactivated in destination org as the current instance and code or build is taken during deployment .So make sure to form these only at time of deployment 

2)Approval process are available ,groups and queues can be deployed .If any issue its better to form queues and groups manually as this is simpler than debugging issue 

3)Be extra careful in adding metadata to changeset that have recently modified by salesforce during salesforce API release .An example to quote ,in winter 14 release only my sandbox was updated to 29 and my production was still on 28.0 and salesforce made some changes to Topics object and some unknown error was received during deployment .In order to avoid this i preferred removing that permission sets .

4)If some components is not getting deployed and if its config build and small effort prefer manually creating and removing same from changesets .Good thing about changesets is changesets can be cloned .

Hope this was interesting post!!Happy deployments and coding !