How to increase the quality of your Salesforce code with Git and code reviews.
As Salesforce developers and admins seek the holy grail of Continuous Integration, many are making the wise decision to automate more and more processes.
Are you doing manual deploys with change sets today? — Reduce your likelihood of human error by setting up an automated script with Jenkins (or use Blue Canvas to deploy…) Still doing manual QA? — Cut down your shipping times with automated testing like Selenium. Manually looking for syntax errors? — Use a linter!
Just keep in mind: Automation can’t catch every issue. The best way to improve code quality & save time is the good ol’ code review.
“Code reviews ensure that multiple members of your team have at least seen each line of code in your Salesforce application. Every line of Apex, every Visualforce Page, every Workflow rule gets multiple sets of eyes.”
Unlike the difference between Continuous Integration and Continuous Delivery, a code review is a mercifully simple concept to understand. Code reviews are aptly named since they are essentially the practice of having another developer on your team review your code before you merge it upstream.
Code reviewers are looking for a number of things:
Are there any errors in the code’s logic? Are there any edge cases that we haven’t thought of? Is this going to get us into trouble when we scale to more than 10 users? Does this code comply with our style guide? Is code sufficiently clear and well commented? Will it be easy for a new team member who didn’t write this code, or even the person who wrote it, to understand what is in twelve months?
Does this code sufficiently address the requirements as they were written down? Are any features missing?
Are there any new tests that need to be written as a result of this new code? Or do we need to update any old tests to account for these new changes to our application logic?
Salesforce Developers will be a lot happier and sleep better at night if they implement a regular code review practice.
The main reason to do code reviews is to ensure that your code quality remains as high as possible. Code reviews limit the number of bugs that make it into production.
Though most understand why code reviews lead to higher code quality, few appreciate the ways in which code reviews drastically improve your team dynamic.
Code reviews ensure that multiple members of your team have at least seen each line of code in your Salesforce application. Every line of Apex, every Visualforce Page, every Workflow rule gets multiple sets of eyes.
This reduces the “bus factor” on your code base. If one of your developers or admins leaves for another job, you aren’t caught in the unpleasant situation of having no one understand a major piece of logic or feature.
“One of the best ways to improve code quality and save time is a code review.”
It also lets people go on vacation. You’re never in a situation where you have some critical piece of infrastructure go down and the only person who knows how it works is backpacking the Appalachian Trail without cell service.
In general, collaboration is a positive thing for software development. It’s often really useful to get a second, third or even fourth set of eyes on a problem. If you’re having trouble with something, it’s generally nice to be able to turn to other members of your team for ideas. Ideally they won’t be seeing the section of the code base you are working on for the first time and can readily provide feedback and act as a sounding board. Code reviews help facilitate this kind of interaction.
Code reviews allow you to get new members of your team up to speed more quickly. Whether they are extremely senior or brand new to software development, code reviews help people come up to speed on the specifics of your Salesforce Org quickly.
Our reader Cory Cowgill pointed out that we had missed one of the key benefits to Code Reviews in our initial draft of this article: security. Many Salesforce developers use tools like Checkmarx to do static code analysis to look for vulnerabilities. But these automated scans can only do so much. Code reviews can catch crucial issues that automated tests cannot.
Counterintuitively, code reviews will save your team time. Code reviews let you catch bugs before they make it into production. Code reviews ensure that your tests are always up to date. Code reviews help prevent technical debt that will need to be paid down later.
Salesforce deployments are slow and rollbacks are difficult, so it’s really important to get things right before starting the deployment process. A small amount of time invested on a code review up front will save you a lot of time in the long run. You don’t want to be deploying to your Org only to find something has broken after 4 hours of testing. Let a code review catch it early.
Code reviews should generally occur before merging upstream. In a typical Git workflow with Salesforce, a developer will create a new branch for their work. Once they are happy with their new feature, they issue a pull request to merge their branch upstream into the next branch. Typically with Salesforce this would involve doing a code review before pushing to a sandbox or developer edition Org. This puts another set of eyes on the code before it gets too far in the process.
“Even if you haven’t yet perfected your code review process or adopted true CI, you can still benefit from getting your team to collaborate more closely”
Once this is looking good in a sandbox, you’re going to want to push it to your staging environment and run more tests. While those automated tests are running, ask another engineer to do one final code review. Look for the things we discussed above. If it looks good and all tests are passing you can deploy to production.
Of course, every team will have different requirements and capabilities from their code review process. Smaller teams may only do one code review while larger teams might do more at each stage. Experiment with what works best for your team
Salesforce development is unique because of its “clicks not code” philosophy. Code reviews will still benefit features which are created declaratively through the Salesforce UI. Have developers review changes made by admins and vice versa. This ensures that all functions on your team understand and agree with changes that are made. Admins can help developers think through the business logic. Developers can help Admins think through bottlenecks and speed issues.
Git is the essential tool for code reviews. Code reviews work best when it’s possible to create branches for your code which are separate from the master branch. Git makes this really easy. Git also makes it easy to diff what has happened in the new branch compared to a previous branch.
Blue Canvas makes this especially easy. Blue Canvas allows you to quickly visualize what is different between different Orgs. Using our Compare feature you can see line by line what is different between production and staging or staging and a development edition Org.
The great thing about code reviews is that they are very simple to implement. Even if you haven’t yet perfected your code review process or adopted true CI, you can still benefit from getting your team to collaborate more closely. And to do that you can start today.
How to rollback a Salesforce change using Git without having to use the command line.
Does the "power law" math that VCs espouse really work for founders?