Verify a managed application deployment
Goal
Confirm that an approved pipeline application version reached its managed environment and that one bounded read or write behaves as documented.
Prerequisites
- an onboarded repository and environment;
- a merged application change with passing required checks;
- the deployment status surface supplied during onboarding;
- a non-destructive smoke request and expected result.
Steps
- Record the merged commit identifier and generated application version.
- Wait for the managed deployment status to report that exact version healthy.
- Authenticate with a workspace credential.
- Run the application's smallest owner-scoped read or idempotent smoke request.
- Compare the response with the example committed alongside the application.
- Record the version and result on the originating issue or pull request.
Expected result
The status surface and smoke response name the intended version. The request returns only records owned by the authenticated workspace and matches the documented response shape.
Keep a useful verification record
Record the commit and deployed version, environment, check time, expected result, observed result, and any unresolved limitation. Keep credentials and customer records out of the issue; use designated test data and redact identifiers where needed.
For a write workflow, check that a test record survives a refresh and a new session. Use a second authorized test identity to check that private records cannot be retrieved across account boundaries. For an integration, verify the failure and retry behavior as well as a successful response. Agree on safe cleanup of any records created by the check.
Before accepting important data, document the backup and recovery procedure. Rehearse a restore in a separate environment. A code rollback may not reverse a data migration, so record which versions can read the stored data and who owns recovery if verification fails.
The public website repair case study shows how deployment checks can cover both successful routes and deliberate missing-page requests. Its technical results are separate from later search performance measurement.
Failure modes
| Symptom | Check |
|---|---|
| Status shows an older version | Wait for the managed deployment or ask the operator to inspect the blocked stage |
| Authentication fails | Refresh the workspace credential; do not place it in an issue or log |
| Empty result | Confirm the workspace owns fixture data and that the query bounds include it |
| Contract differs | Stop promotion and correct the implementation or generated reference in a new pull request |
Reference
The data platform preview defines ownership and compatibility boundaries. The tickets walkthrough is a complete application-level example.
Validate a pipeline application change
Review the schema, manifest, transform, and public contract of a narrow application before publication.
Build, launch, and grow one project
Carry an application from its first working feature through users, payments, tests, web delivery, mobile-store preparation, marketing, and ongoing improvements.