Our approach to developing global features for multiple similar but not identical Salesforce organisations.
Our Salesforce Organisation Landscape
We currently use three country-specific Salesforce organisations (orgs):
- UK Salesforce org - our greenfield implementation
- US Salesforce org - inherited via the acquisition of Endurance Lending Network
- Continental European (CE) Salesforce org - inherited via the acquisition of Zencap
All three orgs use very similar data models to support similar business processes but they are not identical because they were built in parallel by three different companies.
Each org has a different set of integrations with country-specific backend applications and third party Salesforce apps.
Although the deployment process was similar for each org, they all use separate source code repositories. Any re-use of features between orgs was achieved by manually copying code and metadata from one repository to another.
We needed a deployment process and development methodology that facilitated the following:
- Build once and deploy into all three orgs without having to copy-paste code between repositories
- Development of global features but allow local customizations
- Development of local features that need/will not exist in all three orgs
- Gradual move to a single codebase as a long term goal
- Not add disproportionate overhead
Single Deployment Process
With these goals in mind, we designed and built the new deployment process by making the following changes.
New Global Repository
We added a new source code repository that would contain the global features and be org-agnostic. The global features will comprise a super-set of sub-features required by all the countries. These sub-features can be switched on or off in each org using custom settings/metadata. Country-specific features will continue to remain in the existing local repositories.
New Trigger Framework
A new trigger framework was introduced to handle triggers in the global codebase or the local codebases based on filters that can be configured using custom metadata.
To deploy a global feature (usually initiated by a merge into the master branch of the global repository), three parallel jobs will be executed, deploying to the three orgs. Each job will merge the master branch of the global repository with the (unchanged) master branch of one of the country-specific repositories and validate the merged code into the relevant org. If any duplication of files is encountered during the merge, the deployment will fail and require manual investigation.
After all three validations have succeeded the code would be deployed into all three orgs.
To deploy a local feature (usually initiated by a merge into the master branch of the local repository), a single job will be executed. This job will merge the (unchanged) master branch of the global repository with the master branch of the local repository and deploy it into the relevant org. Again, if any duplication of files is encountered, the deployment will fail and require manual investigation.