Two Errors in a Saturday Deployment Plan
Meridian Bank is promoting its lending application to Pre-Production from release candidate tag RC-2024-11, created Wednesday. The application has 40 modules across Development and QA. The generated deployment plan lists 12 modules as new versions, 5 as unchanged, and raises two errors: the shared Common module sits at 0.1.9 in Pre-Production but 0.1.11 in QA, and the Integrations module references a module that exists only in Development. The change window is Saturday 02:00 to 06:00. Six of the modules in the plan were published to QA on Thursday and Friday by a different team, after the tag was cut. The release manager wants to resolve the errors by including every module shown in LifeTime so the plan compiles, and argues that Pre-Production is only one environment away from Production so the risk is contained. Deployment to Production is booked for the following weekend.
1. What should the release manager do on Friday afternoon? Explain why "include everything so the plan compiles" is not a resolution.
Read the worked answer
The correct action is to stop, reconcile the plan against the tag manifest, and re-plan deliberately. "Include everything" makes the plan compile by silently changing the release content, which is precisely the failure a deployment plan exists to prevent.
Concretely:
- Open the tag manifest in LifeTime and list the module versions that RC-2024-11 actually contains. That list - not the current state of QA - defines the release.
- Remove the six modules published Thursday and Friday if their tagged versions are older. Including them ships another team's two-day-old, untested-in-this-context work into a Saturday window, and it invalidates any test evidence gathered earlier in the week.
- Resolve each error against the manifest rather than against "newest": if the tag records Common 0.1.11, Pre-Production is simply behind and adding it is correct; if the tag records 0.1.9, then QA has drifted out of band and 0.1.11 must not travel.
- Add the missing dependency explicitly. A module referencing a module absent from the target cannot be deployed; include the dependency and everything that depends on it, as one set.
- Re-run validation after any plan change, because the compiled plan is the thing that was tested.
The "only one environment away from Production" argument is backwards: Pre-Production is where you want the exact Production-bound set exercised, so contamination there propagates one week later. If the plan cannot be made coherent before the window, defer - a missed window is cheaper than a Saturday incident.
2. Explain, using OutSystems deployment semantics, why Pre-Production holds Common 0.1.9 while QA holds 0.1.11, and what determines the correct resolution.
Read the worked answer
An environment only ever receives what was deployed to it. Pre-Production at 0.1.9 means the last promotion into Pre-Production carried 0.1.9; nothing since has moved. QA at 0.1.11 means a later deployment - possibly a different team's tag, possibly a direct publish - carried 0.1.11 there.
This is normal drift in a multi-team landscape and is not itself an error. The error appears because the deployment plan is compiled against the current state of the source and target environments, so a mismatch between them surfaces as a version conflict. LifeTime is telling you the two sides disagree, not that one of them is wrong.
The resolution is determined by the tag manifest, not by version numbers:
- If RC-2024-11 records Common 0.1.11, the plan is right to include it. Someone must confirm 0.1.11 has been exercised in Pre-Production with the rest of the release, because a shared module upgrade changes behaviour for every consumer.
- If the tag records 0.1.9, QA's 0.1.11 arrived out of band. Exclude it, and investigate who published it, because that publish is invisible to every downstream environment and will resurface at the next promotion.
The same logic applies to the missing module: a module that has never left Development cannot be assumed into existence. It must be promoted as part of the release, with its dependents, and the set must be validated together.
The general rule worth stating to the release manager: deployment plans are version-set contracts. Any edit to the set is a change to the release and requires the same scrutiny as the original tag, even if the edit is a single "allow" click.