Version control, for most developers, is an absolute must in any professional setting. Many developers would say as much for any development scenario, professional or otherwise. However, in the face of budgets, deadlines, learning curves, and just plain laziness, it’s tempting to forgo the effort for “more productive” efforts like the coding itself. Why spend the effort when chances are you won’t need any version of your code but the one you end up deploying? Version control is one of those things that you don’t need until you’re already regretting not having it.
For many developers and the blessed souls that work with them, this is a tired tune they’ve heard over and over again. If you’re in this category, feel free to skip to the challenges your developers are going to face. For the rest, the cowboy developers and corner-cutting budgeters:
Why Even Salesforce Needs Versioning
There are many, many, many articles in the wild detailing the why’s of version control. However, as with many Salesforce topics, things are a bit sparse. According to John Vogt of Salesforce, they are working on a native versioning system, but until then the only piece of literature that I’ve come across that touches on enterprise-level version control for distributed teams working on Salesforce and the trials and tribulations therein was a workflow from Atlassian, which is incomplete but very promising.
Now, the most common logic against versioning by new Salesforce developers is that every time a Salesforce developer hits the save button on the most widely-used Salesforce IDEs, that file gets saved into the Salesforce cloud, safe and sound. It’s tempting to rely on this behavior as a back-up plan for written code. This ignores the potential for the loss of previous versions of code. This is especially concerning in the world of VF/Apex coding, with all its quirks, gotchas, and constant evolution. A developer could go down a certain path for hours, thinking they’ve got the right solution for some function, only to find that it turns out the paradigm they’d planned for doesn’t work, or the release around the corner is going to render what their working on obsolete, or what have you. If they need to go back, but didn’t save the previous versions of their work, much more time will be spent making their way back. Even if the previous versions were saved somewhere, somehow, there will be too many to keep track of. Bottom line: cloud-stored code alone is not a backup contingency.
Salesforce Versioning Challenges
There are a several major hurdles in regards to versioning Salesforce, the core of which lies in the fact that typically, version control is designed for locally compiled applications. Salesforce, on the other hand, is compiled elsewhere and involves much more than just code in the form of XML metadata, thus:
1) Salesforce must be deployed in order to be compiled, and thus the compilation/deployment process must be intimately intertwined with the version control process. This can complicate things immensely.
2) If one is to utilize versioning to its fullest, one must include the metadata files, which often dwarf the Apex code base. Versioning the XML metadata files, however, can be a bit touch and go for the more C++/java-focused version control systems.
3) Some metadata (i.e. profiles, permission sets, and occasionally the package.xml) gets changed automatically on the server depending on the conditions of the compiling org.
4) If every file in the org is included in every branch, including every profile, workflow, page layout, email template, etc, it could take upwards of an hour or more to perform deployments. This just isn’t practical for daily development in 2015, and so:
5) You have to shorten your deployment/compiling time not having every file in every deployment/compilation, which means you can’t use the same project between branches, and every branch will have a different set of files. This is because the set of files in each Salesforce project must perfectly match the package.xml file. Ever write code that depends on stuff that isn’t even in your local project?
6) If anything is deleted, destructive changes must be deployed to every other org. This might be OK for deploying destructive changes to every developer on a branch, but what if you need to go backward, or you need to patch production mid-project? You can’t do that unless you delete anything that got introduced in the interim versions. Thus:
7) Every currently active version of the project, whether the current new version branch or issue branches, needs its own set of SDLC orgs (dev, QA, UAT, etc). Be ready for spinning up a lot of new one-off developer orgs and/or refreshing orgs from production.
Now, don’t let this list scare you. It makes versioning Salesforce a little more complicated than you may be used to, but remember what versioning means to your productivity and you’ll again be willing to take on this challenge. In the next article I’ll go over what we did to get our double-digit-sized team all synced up. Our approach used an article from Salesforce’s technical library as a basis for our versioning process. After some back and forth, we went with using TFS coupled with an Eclipse plug-in and its continuous integration capabilities to coincide with the Microsoft tools already in use, and I’ll cover this process as well.