2

I'm trying set up a development model in our organization using SFDX and scratch orgs. Following the SFDX Trailhead modules, I see that only the particular project at hand is being sourced.

How can I keep a constant baseline of an org as it stands? I'd like our development team to be able to have the full codebase to start with and create branches from that existing base. Is this not how SFDX was designed?

|improve this question
4

DX works well with multiple "packages" within your git project. In fact, I'd recommend this, as it allows easier merging and branching strategies, and you only need to deploy pieces at a time. The Trailhead examples are intentionally simple, because it's not supposed to be an entire org example, which would take much longer to understand.

For example, in our current design, we have tentatively adopted the following design:

  • force-app/core: contains core metadata (those shared across all packages)
  • force-app/marketing: contains marketing metadata and logic
  • force-app/support: contains customer support metadata and logic
  • force-app/utils: contains utility components and classes
  • ... Other packages that are not dependent on core packages
  • src: old metadata API format metadata that has not yet been converted

This design allows us to install just parts of our org in to sandboxes/scratch orgs, reducing the amount of time it takes for us to spin up a new development cycle, as well as minimizing the deployment time by using unlocked packages with dependencies. We can also migrate our code from the old repository format to a new format with minimal fuss as developers are working on older features.

All of this metadata exists in a single repository, so all code is available to all developers, and SFDX allows us to write shell scripts to deploy various configurations to any org, even production.

|improve this answer
  • How do we only deploy certain parts of the whole repo to a scratch org? Currently if we try to deploy a whole codebase, it takes up to an hour to deploy to test in a scratch org. Do you choose certain pieces when creating the scratch org? – Kyle J V Sep 19 at 17:38
  • @KyleJV Both force:source:deploy and force:package:install allow you to quickly install just chunks of your metadata. Depending on your exact development style, you may also force:source:push and/or force:source:pull to synchronize changes. In any case, this should significantly reduce spin up time for a new org. – sfdcfox Sep 19 at 18:09
  • What is included in your core metadata? Just standard/custom objects and Apex? Do you include things like permission sets? Our current base hardly has anything beyond standard and NPSP in it and it takes a long time still. – Kyle J V Sep 19 at 19:07
  • @KyleJV Our core package consists of Account, Contact, Asset, and custom objects that support our business model. There's a package for Sales (Opportunity, etc), Marketing (Leads, etc), Customer Support (Cases, etc). Permission Sets reside with the relevant package. Same thing with code. – sfdcfox Sep 20 at 0:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.