There are loads of Salesforce developer guides and Trailhead courses that can teach someone how to be a good developer in Salesforce, but one of the things that I was never fully prepared for was working in a Salesforce org alongside several other developers. Being a lone developer is easy–you alone make changes to the environment and you alone are responsible for keeping track of and deploying those changes. But when there are several developers in a Salesforce org, it can become overwhelming. Changes being made by one developer can easily interfere with other people’s work, and it can quickly feel like there are too many cooks in the kitchen. I’ve learned that in order to work effectively, the team must agree on a set of development practices to manage the work being done. Below is a set of best practices that I’ve found effective on our projects at Red Argyle.
Source Control
This first suggestion should be obvious to most developers, but I’m still surprised when I start working in an org that doesn’t have source control set up for their code. Source control, also known as version control, is a system for keeping track of changes to the codebase. Each developer commits his/her changes along with a comment describing the changes. This allows for a detailed history of all changes that were made to the code, along with a story that helps explain when and why those changes were made. Source control can be a lifesaver when trying to find and fix bugs, but it also simply adds accountability so that the team can be aware of changes that other developers are making. There are a number of options out there for source control management, but at Red Argyle we use Git and we host our code repositories on Bitbucket.
Apex Enterprise Patterns
As a Salesforce org grows, its codebase will often grow along with it. Over time, controllers and triggers can grow to become large and unwieldy. It’s not uncommon to see an Apex controller with over 1,000 lines of code. This can be challenging for a single developer to manage, but throw in a couple more active developers and you’ll end up with a confusing mess of code and people overwriting each other’s changes. Breaking down code into a pattern of modules and libraries allows for a clear structure that ensures developers can effectively add new code and manage existing code in the future. By following a pattern that everyone agrees upon, new developers will have an easier time jumping into a project and existing developers will have an easier time fixing bugs and building new features. This Salesforce article provides a good overview of Apex Enterprise Patterns along with a list of resources to get started.
Deployment Plan
With several developers in a Salesforce org, it can be hard to keep track of exactly what changes were made and what needs to be deployed. Source control can definitely help with this, but not everything in Salesforce can be easily tracked with source control. We’ve found that it is important to maintain a deployment plan which contains a list of everything that changed and any dependencies. This can serve as a final double-check before hitting that Deploy button. There are a number of different ways to keep track of this plan, such as creating a Word document or using the Deployment Plan field in JIRA. Different teams will prefer different solutions, but we’ve found it very helpful to have this information recorded in some way.
Set Up Audit Trail
One of my favorite recent additions to Salesforce has been the Setup Audit Trail object. This object keeps track of the information related to changes that are made to a Salesforce org, including the timestamp, the change that was made (such as enabling a Validation Rule), and the user that made the change. Setup Audit Trail works as a great last resort for when a change was made but you don’t know who did it or when it happened. You can access this new object from within the Setup section of Salesforce. The page is pretty simple right now, but if you need more details you can download a spreadsheet containing the last 180 days’ worth of changes or you can even use SOQL to query for the data. Check out Andrew Fawcett’s blog post for some more details on this new functionality.
As with any system, once there is a blend of moving parts and a number of people actively making changes in a Salesforce org, it becomes important to determine processes that will help maintain the efficiency of the work being done. Over time, our processes have adapted as we realize different needs or find new technologies to help us. Do you have a different way of managing multiple developers in a Salesforce org? Or perhaps there’s a technology that has greatly helped you with this problem? We’d love to hear about it in the comments below!
