Salesforce release management best practices
Achieve success with version control and continuous delivery.
At the heart of what makes Salesforce so powerful is its ability to allow less technical users to develop apps and customizations without writing a single line of code. This unique strength, however, comes with a cost. It makes source control and release management very challenging due to its tendency to introduce multiple competing sources of truth, as well as the cost of reverse engineering click configuration back into code.
To achieve success in adopting Salesforce source control and release management, companies should follow a number of guiding principles that might not be generally required in other software development stacks. Each company will have different release requirements and cultures, but as long as you stay within the best practices discussed below, you should have no problems in moving towards a more streamlined, automated and modern Salesforce release management process.
The best practices below are applied to both metadata api based projects as well as SFDX based projects.
1. Use feature branching and pull requests
Feature branching and pull request is an industry standard for working with Git, yet we still see teams working off shared branches and cherry pick commits to production. If you find yourself continue cherry-picking commits and applying hot fixes, your process needs to be revisited.
Each of your developers/admins should work on his/her own sandbox and commit changes to a feature branch which represents a business change (jira ticket, business request, …). This feature branch will then be merged to integration branches before getting deployed in targeted environments.
2. Track both configurations and code in Git
Configurations like validation rules, workflows, objects & fields are equally important as Apex code and lightning components. Nevertheless, we’ve seen teams who decided to track only code in their repositories and this is a sure path to an unsuccessful release management process. Make sure you track both configurations and code in your repository.
3. Enforce Git as your living source of truth
This is not something to be framed in a document. It needs to be systematically enforced.
The best implementation of this is to setup a continuous integration job that deploys from your Git Repository to your production instance. Any attempts to make changes directly in production (introduce another competing source of truth) will automatically be reverted the next time the continuous integration job kicks off. This puts your entire team in a position where everyone has to respect the release management process and always makes changes in Git first before production.
4. Release smaller changes and release frequently.
Remember that your Git repository must be an active and deployable source of truth and not to be confused with a backup.
For the right reason, you can decide not to track profiles and page layouts in your git repository as the active source of truth (not to confuse with backup), but if you’ve made this decision, you should remove them from your Git repository completely. This also helps your team to easily sync their sandboxes by simply deploying master branch to their sandboxes without seeing deployment errors.
Release frequently is the only way to catch issues early and give you the confidence that Git is your living source of truth.
5. Automated continuous integration job
Setup automatic continuous integration jobs that perform validation as soon as a commit is merged. Build failures block your release management pipeline so make sure you set up a culture where everyone takes build failures seriously and address them in a timely manner.
6. Perform code review
Code review is a standard practice in other tech stacks but hasn’t been done very well within the Salesforce world. Teams who want to be successful with Salesforce source control and release management should make efforts to adopt a code review culture in their process. With the right review tools in place, code review significantly improves quality and make team collaboration fun. It is also a great way for every members in your team to stay in sync of the changes going into production.
7. Empower users with different skill sets to participate in your Salesforce release management process.
Salesforce is unique in that the platform empowers not only developers but also less technical users like business analysts and admins. To gain adoption, you need to provide tooling support so business analysts and admins can participate in the release management process without having to learn XML, Git and command lines. Attempt to push those non technical users through the steep learning curves is almost a guaranteed failure in having your team to adopt your new Salesforce release management process.
8. Access control and segregation of duty.
Your Salesforce release management process should be designed where each role should only concern about his/her part of the process. For instance, non technical users can commit to feature_branch but should not be able to merge directly to master branch. QA & release manager should only concern about testing and approving pull requests. Developers focus on code review, approve pull request, code merge and build pipeline.
Your ideal build pipeline, branching strategy and release management process will be slightly different depending on the size & complexity of your Salesforce environment. But as long as you follow the above best practices, you are a step ahead of the game in moving your team towards a more streamlined, modern and automated Salesforce release management process.
ClickDeploy Enterprise was beautifully crafted and carefully optimized based on the above best practices. You can spin up the entire release management process within minutes without having to install anything. We provide all the tooling support so every member in your team with different skill set can feel productive and confidence in adopting a more modern and streamlined Salesforce release management process.
