Font Size: B- B B+

Language Selection

English

Deployment in Salesforce.com

E-mail Print PDF
Still making all your changes directly in production? Then you can skip this story. 
 
For the people who work in a more professional way hereby my best practices for deploying from a sandbox to production;
So the requirements are clear, the detailed design can be made, testscripts and validation documents are being prepared and you decided to make all the configuration changes in the sandbox. Now how are you going to promote your changes to production?
  1. you can do it all by hand, and do all the work twice
  2. you can do it the old-fashioned way (like we did it in the old days ;-)), by creating a package in the sandbox, putting it (in private mode) on the AppExchange and installing the package in production
  3. By using Eclipse
  4. By using Change Sets, the new (ß) feature within Salesforce
>
Change Sets in Salesforce.com
Change Sets in Salesforce.com
Using Eclipse is probably the method a developer would choose. You can select everything you want to include in your project and do a validation
of your selection from within Eclipse. I found that the error messages after validation when vage or completely irrelevant to the actual problem.
 
The Change Sets feature will be the method of choise for administrators and consultants, so this is the one I choose. The first 2 you can always try 
if option 3 or 4 don't do the trick.
 
So before deploying you changes in production I would;
  • Create a backup of the production configuration with Eclipse so you can always roll-back
  • Make the changes to security and core configuration by hand (territories, roles, changes in global sharing and sharing roles, changes in relations between object, e.g. Lookup to Master-Detail)
 
The creation of the change set you have to do be selecting everything you would like to include in you change set. 
Once you have created you change set in the sandbox you can send it to production, there you can do (automatic) validation and deploy with
1 mouse click. Nice Nice Nice.
 
What you should not include in you change set is new or changed profiles. They can mess up your field level security in production. 
Better is to create a second change set to move these profiles to production after you move the configuration changes to production.
After deploying everything, you should check if you did not forget something (by comparing with the detailed design and doing the same system
test as you hopefully did in the sandbox). 
 
1 big improvement would be to have a button which checks all differences between the sandbox and production and puts these changes in a change set
for you, now that would be handy! 
 
Hope this helps...