Multi-org artifacts: shared packages and string replacement
How to deliver one release artifact to several production orgs: string replacement in sfdx-project.json for per-org values, one Dev Hub owning shared unlocked packages, transferring a package between Dev Hubs, checking what each org has installed, and when org-dependent packages fit orgs that grew apart.
Given a multi-org customer scenario, compare and contrast approaches for managing common release artifacts.
~7 min read · 8 practice questions ·
What the exam expects
- Compare ways to give several production orgs one release artifact: shared source with per-org values, a shared package, a branch per org, change sets or manual edits.
- Configure and troubleshoot string replacement in
sfdx-project.json. - Place shared packages in one production Dev Hub, and plan a transfer when packages sit in the wrong Dev Hub.
- Check which orgs have a package installed before releasing a dependent package.
- Judge when an org-dependent unlocked package fits orgs whose unpackaged metadata differs.
Key terms: common release artifact (one versioned set of metadata delivered to several orgs), string replacement (the CLI swapping a string in source files for a per-org value at deploy or package time), Dev Hub (the org that owns your unlocked packages), installation org (where a package version is installed), package transfer (moving package ownership to another Dev Hub).
Key facts
- Detail
replacementsproperty insfdx-project.json
- Detail
project deploy startfrom source format andpackage version create
--metadata-dir deploys- Detail
- String replacement not supported
- Detail
- Error by default;
allowUnsetEnvVariable: trueremoves the string
- Detail
- Never rewritten by replacement
- Detail
- The Dev Hub; use one in a production org
- Detail
- Support case per package; destination not Developer Edition or trial
- Detail
- 033 and 04t unchanged; new 0Ho
- Detail
sf package installed list --target-org
- Detail
- Not calculated
- Detail
- Only orgs affiliated with the same production org
Sources for this section (6)
- Replace Strings in Codedeveloper.salesforce.com (opens in a new tab)
- Know Your Orgsdeveloper.salesforce.com (opens in a new tab)
- Transfer an Unlocked Packagedeveloper.salesforce.com (opens in a new tab)
- package installed listdeveloper.salesforce.com (opens in a new tab)
- Create Org-Dependent Unlocked Packagesdeveloper.salesforce.com (opens in a new tab)
- Change Setshelp.salesforce.com (opens in a new tab)
- Why does string replacement suit near-identical code going to several orgs?
- When does string replacement not run during a deployment?
- Which org type can't receive a transferred package as its new Dev Hub?
- Why can't change sets carry a release between two production orgs?
The questions are free to read. Answers with their sources and self-grading are included with the pack.
Keep reading with the Platform Development Lifecycle and Deployment Architect pack
- Core concepts
- Exam traps
- Worked scenario
The pack includes:
- All 26 lessons of the Platform Development Lifecycle and Deployment Architect guide, with reading progress
- Interactive decision walks and step-by-step sequence steppers
- Inline practice questions and one-click topic practice (8 questions for this lesson)
- An official source cited for every claim
- An AI tutor that answers from the guide
- Unlimited timed practice exams