Mobile and backend teams agree on an OpenAPI contract for a city services app, and CI must fail if staging drifts. What should they automate?
Select an answer to reveal the explanation.
Short Explanation
A contract you never check is a handshake in the dark. Point CI at staging with OpenAPI contract tests so drift fails the build before citizens' phones do. Hoping mobile devs notice missing fields is not a gate.
Full Explanation
When mobile and backend teams agree on an OpenAPI contract for a city services app, CI should run contract tests against the staging API so builds fail when responses or schemas drift from the agreed contract. Automated contract testing protects municipal mobile clients from silent breaking changes before production promotion. Staging is the right place to detect drift while citizens are still unaffected, and failing the pipeline is the desired signal—not a nuisance.
Treating OpenAPI as documentation only and never validating staging against it fails because documentation drifts without failing the pipeline or blocking bad deploys. Updating the mobile app ad hoc whenever a staging field disappears fails conceptually by making clients absorb undetected breaks after the fact. Freezing the backend forever so the contract never needs testing fails as an unrealistic governance substitute for automated verification.
Exam caveat: contract suites should allow intentional versioned breaks; failing forever without a versioning strategy can block legitimate API evolutions the mobile team agreed to. Operational check: remove a required field in a staging-only branch, confirm CI contract tests fail, then restore compatibility or publish a versioned contract before promotion.