What version assumptions does an end-to-end run make when components deploy independently?

### What a green run is actually evidence of An end-to-end result is bound to four things: the set of component versions deployed, the environment they ran in, the data present, and the moment in time. Interview answers usually remember the first and forget that it is a *set* - and a set that no one deliberately chose. When a single artefact is deployed as one unit, the version question is trivial: one build, one result. As soon as components release independently - an airline seat-map front end, an inventory component, a pricing component and a booking component, each with its own release cadence - the run tests whichever combination happened to be live. Three distinct assumptions hide in there. ### Assumption 1: the combination under test is a combination that will exist A shared pre-production environment usually drifts toward latest-of-everything, because every team deploys there first. Production rarely looks like that: one component is two releases behind because its rollout was paused, another is a release ahead because it shipped a fix on Tuesday. A journey that is green against the newest of everything can still break in production on a combination nobody exercised. The inverse also happens - a journey fails in the shared environment against a combination that will never ship, and a team spends a day on a defect that could not reach a user. ### Assumption 2: the combination is stable for the duration of the run If the seat-map front end is redeployed eleven minutes into a nineteen-minute suite, the first half of the results describe one system and the second half another. The report shows a single verdict for two different systems. Worse, the failure looks exactly like nondeterminism, so it gets attributed to test unreliability rather than to a mid-run deploy - and the real signal, that two versions disagree, is thrown away. Mitigations are procedural as much as technical: run against a deployment that is pinned for the window, gate deploys to the target environment while a run is in flight, or run against an environment stood up for that run from a named set of versions. Each has a cost - contention, provisioning time, complexity - and the choice depends on how expensive an uninterpretable run is to the team. ### Assumption 3: one component means one version A rolling or staged release has two versions of the same component serving at once, behind whatever routes traffic. A journey with several requests may cross both, so a step recorded against the new build and a later step against the old one. If the two disagree about a payload shape or a session representation, the journey fails in a way that reproduces only under that routing. This is real behaviour that production also has, so it is not purely a testing artefact - but it must be recognised, or it reads as an inexplicable one-off. ### What to record, always The cheapest and highest-value practice is to stamp the report: **every component's build identifier, the environment name, and the run start and end timestamps**, printed in the header of the result. It costs a small amount of plumbing - each component exposes its build identifier, the suite reads them before and after the run - and it answers the first question of every investigation. Reading them again at the end also detects a mid-run deploy automatically: if the identifiers differ from the ones read at the start, the run is uninterpretable and should say so rather than report a verdict. ### The limit of the level, and what covers it instead The question this level structurally cannot answer is: *can this one component be released on its own, against the versions its neighbours are actually running?* A journey only ever exercises the combination in front of it, so answering that would need a run per candidate combination, and the number of combinations grows with the number of components. Recognising that the combinatorial question needs a different artefact - pairwise compatibility evidence recorded per consumer and provider, checked at build time - is the senior move; the details of that artefact belong to a different discipline and should be handed to it rather than reinvented here. ### How to answer this in an interview Say what the result is evidence of, in one sentence, and then name the three assumptions and their mitigations. The differentiating detail is the mid-run deploy: most candidates never consider that a suite can span two systems, and the fix - read the build identifiers at both ends of the run and refuse to report a verdict when they differ - is concrete, cheap and clearly the answer of someone who has been burned by it.