Bringing production changes back into source control
Why direct production changes make production drift from Git and get overwritten by the next deployment or rollback, how to find them with Setup Audit Trail, retrieve them with Salesforce CLI and commit them through review, how Lifecycle Center teams recreate them, and how to reconcile an emergency fix with open branches.
Given a customer scenario where changes are made directly in production, explain the implications on the development lifecycle and steps to integrate changes into application lifecycle management.
~7 min read · 11 practice questions ·
What the exam expects
- Explain, in stakeholder language, why a direct production change hurts the lifecycle even when it works.
- Predict what the next deployment, rollback or test run does when production differs from Git.
- Find direct changes with Setup Audit Trail, retrieve them with Salesforce CLI and commit them through review.
- Bring a fix into a Lifecycle Center (formerly DevOps Center) pipeline.
- Reconcile an emergency fix with main, open release branches and the lower environments.
Key terms: configuration drift (production differing from version control), source of truth (the repository a team deploys from), manifest (package.xml listing the components to retrieve or deploy), emergency fix (a change made directly in production during an incident), reconciliation (bringing that change into Git, open branches and every environment).
Key facts
- Detail
- Creates, updates or deletes the components in the package
- Detail
- A deployment's assignments replace all existing ones
- Detail
- Redeploy the previous version; no native rollback command
- Detail
- 20 most recent changes; Download covers 180 days
- Detail
- Records deleted after 180 days
- Detail
- Monitors Metadata API deployments, not Setup edits
- Detail
- Excludes managed and unlocked package metadata by default
- Detail
- Never available in production;
--ignore-conflictshas no effect there
- Detail
- Development environments only
- Detail
- Merges to the next stage's branch, then deploys forward
Sources for this section (9)
- deploy()developer.salesforce.com (opens in a new tab)
- Special Behavior in Deploymentshelp.salesforce.com (opens in a new tab)
- Operational Excellencearchitect.salesforce.com (opens in a new tab)
- Setup Audit Trailhelp.salesforce.com (opens in a new tab)
- Deploy Your Changeshelp.salesforce.com (opens in a new tab)
- project generate manifestdeveloper.salesforce.com (opens in a new tab)
- project retrieve startdeveloper.salesforce.com (opens in a new tab)
- project deploy startdeveloper.salesforce.com (opens in a new tab)
- Lifecycle Centerhelp.salesforce.com (opens in a new tab)
- Why does a direct production change that works still put the next release at risk?
- When does Setup Audit Trail stop helping you find a direct change?
- What does a deployment that contains page layout assignments do to the assignments already in production?
- Why is a second retrieve from production never incremental?
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 (11 questions for this lesson)
- An official source cited for every claim
- An AI tutor that answers from the guide
- Unlimited timed practice exams