Holding a Security Update When One Stack Fails Stage
A security advisory requires a Drupal core update across 450 sites. The factory has stack-a (300 sites, standard profile), stack-b (100 sites, commerce), and stack-c (50 sites, legacy custom module). The update passes automated tests on stack-a dev and stage. On stack-b stage, 6 sites show checkout errors after 10 minutes; logs point to a deprecated payment gateway library. Prod deployment for stack-a is approved for tonight; stack-b and stack-c are not. The vendor says a patch for the gateway will be available in 48 hours. A stakeholder asks to deploy stack-a and stack-b together to 'save a window'.
1. Should stack-a and stack-b deploy together tonight? Justify your answer.
Read the worked answer
Reasoning: Code deployment is stack-scoped. Deploying stack-b would push the same code to all 100 commerce sites, including the 6 that already failed stage.
- Do not combine the deployments. Stack-b has not passed stage; a known checkout failure is a revenue-impacting defect.
- Deploy stack-a tonight because it passed dev and stage and has an approved production window.
- Hold stack-b until the vendor patch is applied and the 6 failing sites, plus a sample of others, pass checkout testing.
- 'Saving a window' is not worth exposing 100 commerce sites to a failure already reproduced in stage.
2. What rollback and verification plan should be in place for stack-a?
Read the worked answer
Reasoning: A security update can change behavior even when tests pass, so the team needs a defined rollback point and observable checks.
- Record the previous code tag and confirm database/file backups for a representative set of sites.
- Before deployment, define smoke tests: anonymous browse, login, search, forms, and cron.
- After deployment, monitor error logs, PHP logs, and checkout or form failures for at least one traffic cycle.
- If error rates exceed the agreed threshold, redeploy the previous tag and restore affected databases only if data corruption is observed.
- Communicate the rollback decision path to support before the window opens.
3. How should the team handle stack-c and the stakeholder pressure?
Read the worked answer
Reasoning: Stack-c has a legacy custom module, so stack-a's success does not prove stack-c is safe.
- Validate the update against the legacy module in stack-c dev, then stage, with functional tests for the custom behavior.
- Do not deploy stack-c on the strength of stack-a's results; treat it as a separate change with its own risk assessment.
- Give the stakeholder a written sequence: stack-a tonight, stack-b after the gateway patch and retest, stack-c after legacy validation.
- If the advisory severity requires faster action, ask the security owner to document a risk acceptance rather than silently accelerating an untested stack.