Source Control Forgotten
I want to take a bit of time to remind other Force.com platform developers of the necessity and benefits of using a version control system. Because Force.com is a managed platform and handles so many of the responsibilities and tools for the developer, it is possible that some necessary software development tools were forgotten in the shift to the cloud. I believe that source control is one of the forgotten tools that needs rediscovering. With rapid development iterations, you will probably find a time when you have to roll the code back to an earlier, more stable, version. Because we are working on a platform that does not easily allow tight integration with source control, we must take the initiative to start using it. I don’t intend to give a detailed how-to in this post, I just want to run through a few scenarios in which you will be glad that you have version control in place.
Let’s walk through a deployed code failure situation. We just finished deploying a few classes that adds new functionality. It passed all automated and manual testing before deployment, so it should perform with no problems in production, but in reality, it failed hard. These things happen, and they are difficult to completely avoid, so don’t feel too bad about it. We can learn from the experience, and we can take counter-measures to reduce the chance of it occurring again, but for now, we have to revert the code back to a working state.
Using the Vanilla Force.com Process
Let’s say that the solution to the problem is not immediately obvious, and we have to revert the code back to a working state so that we can take our time to debug the problem. Using just the tools that Salesforce provides in the UI, we have to manually find all the files that were modified in the last release, comment out the old functionality, run unit tests, and finally deploy back to production. This is a very manual and error-prone process and the chances of forgetting to remove some code is very high.
Using Version Control
Let’s walk through a development process that uses a version control system. The only way to add our code to a version control system is to use the API to retrieve the code and store it in individual files locally. While developing, each time we have a new piece of functionality that is performing successfully when uploaded to the dev sandbox, we make a snapshot by committing the code to version control and naming it after the working bit of functionality it composes. When we continue to work on Functionality B and consider it complete, we make another commit to the version control system and call it something like “Functionality B Complete”.
With these commits in place, when Functionality B breaks and we need to revert back to Commit A, we have two options. Option 1 is to use the diff tool that is included with most version control systems to compare the current version of the code to an older committed version. Most diff tools, such as the one included with Eclipse, will also allow you to selectively and easily revert bits and pieces of a file to match the older commit. We don’t have to rely on the error-prone method of manually searching for pieces of code that we think has changed, we simply look through the noted changes and decide whether to remove it. Option 2 is to forego the selective replacing, and instead revert the entire file or code base back to Commit A. It is easier and the more desirable method in cases like this, when we quickly want the production org back to a working state.
Creating Change Sets
Another positive side-effect of using a version control system is seen when creating change sets. When deploying changes from a sandbox up to a test or production org, we are required to select specific files to include in the deployment to the test or production org. I know there are many developers out there that spend a good amount of time reliving the last week or two of their development life, trying to recall the files, validation rules, and workflows that they touched. This type of manual reproduction is error-prone and should be avoided, if possible. A feature of version control systems is their ability to produce a list of all changed files in a commit. We can directly use these lists to reference as the list of files to include in the deployment! Time-saver!
If the Force.com platform kept a history of each saved version of the code, we could simply click to quickly revert to the older version, but unfortunately, the Force.com platform does not provide this facility. If you have ever been pinched by version control problems in Salesforce, you should upvote this idea on the IdeaExchange to help convince Salesforce to add native version control. Every vote counts!