Simple Solution — SFDC Source Control
I have been working on SalesForce platform for quite some time to be an evangelist. Platform is great and there is not doubt about it. What I really don’t understand is some IT problems which I want to share the problem statements and yes simple solutions.
I have been part of complex implementations and I absolutely love the platform on how well one can get creative about designing solutions using all great SalesForce features. Out of all awesome features there could be absolutely more awesomeness can be added to the platform where most commonly every team does.
One such topic is source control system/mechanism for SalesForce.
The story starts like this,
Sales VP : “Yes, we need SalesForce.”
PM: “Awesome! Let’s do it.”
Sales VP: “What do you need?”
PM: “A Team”
Sales VP: “Go Build One”
— — — Time Lapse — — —
PM: “Good News!! We rolled SalesForce”
Sales VP: “Great”
Lot of customization will be added with in no time. Before anyone realizes what is going on, it will be too late for some house keeping things. Since issues pop up quickly then comes the optimization, governance, efficiency, effectiveness, importantly lessons learnt.
From lessons learnt comes with “Aha” time. “We don’t have a source control”. Immediate thoughts are what is available in the market and what it takes to implement.
“Git”, obviously very popular, likewise there would be tons of tools on the table to choose from. Now speaking of Source Code Control, SalesForce is a multi tenant architecture and can use resources in a very well balanced manner.
So, why can’t SalesForce story versions of each component type based on the package deployed? Just like history table for every object, #DeployHistory could be another object and same history recording mechanism could be used to store the source and therefore establishing versioning.