Parallel Development in Salesforce: A Modern Approach
This article will explore a story about a fictitious team working on a large Salesforce implementation project that goes beyond a small implementation. It demonstrates the troubles they encountered and the solution they ended up with. It illustrates the development team at CoreForce, and their first foray into SFDX and unlocked packages. They needed 3 separate teams of developers to work on an application independently, each with their own package without having to worry about stepping on each other’s toes.
The idea of storing the entire project within one shared repository was not ideal. Asha’s team didn’t want Bob’s team interfering with their code. Having so many components in a single repository would get complicated. Coupled with the fact that their Salesforce vendor, VendorsUnlimited, had a separate release cycle. Their sprint was over 4 weeks long, while Bob and Asha’s teams wanted to release every 2 weeks. Valerie, the director of engineering, instructed the teams to break up their project using SFDX Unlocked packages.
Asha, Bob, and Carl, developer managers at CoreForce, were tasked with designing an SDLC for Salesforce DX. In attempts to garner some knowledge, they ran with the pre-assembled EasySpaces app to practice. EasySpaces is an opensource, multiple package SFDX project.
At first, when the single repository strategy was suggested, the team was optimistic. They took the project head-on, working on a proper git-flow branching model. They had nearly assembled their entire project before they ran into their biggest problem.
“This won’t work. Our vendor wants to keep a copy of the code in their own source control system and only check in to ours once they get it to a stable state. We can’t have a single project housing all of these packages,” Carl stated. “On top of that, I have Bob’s developers meddling with my package. The versions are all messed up and the source code is all fumbled.” Having spent weeks building out an entire development process around their original strategy, it was back to the drawing boards.
The team sat around the scrum room, armed with multi-colored expo markets. Bob lifted his head, “How about we try submodules?”
“Sub-who?” Carl rang.
“Git submodules..we could house one of their repositories within ours, without having access to it! We would be able to work on and edit our packages.” It seemed intuitive, but it opened up more questions.
“How many submodules would that entail? There’s 3 of us, so that’s already 3 submodules. What if more packages are introduced? Holding so many submodules which have to link to each other sounds disastrous. There’s no possible way anyone could keep track of that.”
“How else? The packages have to be in sync right? We can’t share them in one repo. They’re dependent on each other. There’s no other way to do it.”
“There’s a reason they’re called sobmodules.” Asha chimed, “Maintaining a proper CI/CD process would be impossible. It’s incredibly easy to overwrite commits, destroy work; it just wouldn’t make any sense.”
“I’ll leave it to you to figure something out then,” Bob muttered.
The team debated. No one really knew how to argue this issue. Developing with Salesforce is different than developing an average Java or .NET application. Asha was right though, git submodules would just make things complicated. Lifecycles are separate, git doesn’t recognize submodule updates, and the teams would have to be in sync with the vendor regardless to avoid overwriting commits. The purpose of a submodule is more or less for unstable APIs and plugins. This was not an applicable case.
The room went quiet for a while. They had to present their findings by the end of the day, and they only had about five hours remaining until then. Asha sat at her computer, eagerly researching. She thought about the way SFDX is structured. She wondered about orgs, and access to them. After some time, Asha lit up. She stood up from her seat, prompting all eyes in the room to focus their gaze. “Packages are stored in the org. We don’t need access to anyone’s repository. As long as VendorsUnlimited installs their package into our shared org, we can still work on our dependencies.”
“How would we be able to access that though?”
“We have permission sets that add access to the data.” Asha leaped to the whiteboard and worked out her diagram.
Thus, the developers developed a plan for the multi-repo approach.
They found that a multiple repo approach would be best suited for most SFDX project that contains multiple packages. A Multi-Repo approach gives the developer teams the option to work on their own package without messing with other development teams/packages.
The EasySpaces codebase is a great introduction to SFDX and unlocked packages. It follows the typical paradigm of “multiple packages per code repo”. One reason that they do this is that they are trying to show a concept that would normally be spread out over multiple code repositories. For ease of reading, they consolidate those projects to a single repo. While that approach helps with reading code, it is not the best approach for long term development operational needs.
There are multitudes of developmental approaches that would suit a good number of simple projects. A mono-repo approach would best be suited for a project that either contains minimal packages or isn’t complex to begin with. It’s also an easy approach for a small team of developers that can trust other developers for not messing with their own appointed package. Changesets are also common for small projects that don’t use deployment. However, for the purposes of large complex projects that utilize different development teams and require the deployment of large-scale applications, multiple repositories would be the ideal solution.
Asha, Bob, and Carl worked tenaciously to develop and document their process. They spent weeks refining the process to present to Valerie. Because this was a relatively new concept and not a lot of documentation was available to readily reference, the team decided to publish their documentation on GitHub. They left it open source, and free to edit. They welcome you to read and review their process. The team now regularly participates in the Salesforce development community, helping other organizations set up the same process.
