Salesforce Release Management

Salesforce always advocates us to make all the changes through its UI. It is nice but hardly a solution for a corporation. In a corporation, we used to develop everything in dev, launch to QA and test it, then launch to production. Salesforce claims its approach can shorten the release cycle. However, I don’t think we want to do thing in this way. For example, if we have hundred of fields to add and the application cannot be used until all of them are in place, what will you do to minimize the impact of users currently using your app? How can we rollback all the changes? How to test the changes before releasing them? Yes, you may get around this via switching layout or making new objects and fields available only for admin user. However, what if we don’t even want our developers accessing production box because the data there is sensitive.

All in all, we want a solution that we are able to develop on our sandbox, test it and push a button to release all the changes to production. To my dismay, I don’t see Salesforce provides us end to end solution in this aspect. To work around, I tell my team to do all the changes in the sandbox (Salesforce provides one if you are in enterprise edition but it only has metadata in it) and manually move the changes to production after test. It is a tedious process and error-prone. Finally, I decide to search around and luckily I found a way to achieve my goal.

Use Force IDE

Force IDE is released that works on the new Metadata API released on Summer 08. It is an awesome tool. Through this, I am able to back up my production metadata in xml format and put them in version control system (ie SVN). With the help of SVN, I am able to tell who has changed what, do a diff on different versions and rollback. It is a great tool for us. But when I look into this tool, I have faced some of the issues. Below are some of my findings:

1. I cannot remove or rename existing fields.
2. There is no standard objects.
3. There is no approval processes
4. If you custom objects have circular dependency, you cannot simply copy 2 .object files into the object folder and assume Force IDE will resolve it for you.
5. I cannot move apex classes to production box.
6. I lose the association between S-Control and button.

However, I am able to get around these via:

1. Rename and delete fields using SF UI.
2. Modify the package.xml to enable standard object synchronization. (detail)
3. Use SF UI to add approval process
4. Manually create the custom object via SF UI first. Then you can copy all the fields to it via Force IDE.
5. Apex class cannot push to production unless you test it and deploy it via the migration tool.
6. Manually associate the S-Control with button via SF UI.

However, although we cannot make release management simply pushing a button, we can live with that as Force IDE already does a lot for us.

Backup Strategy

Now we know how we deal with metadata and simplify the release management via Force IDE. How about backup the data? Salesforce provides us DataLoader tool that we can use to export Salesforce data in CSV file format. Apart from that, you can import the CSV file back to Salesforce.