Project: prove a self-service platform request end to end

Last updated: 5 Oct 202610 min read

project

Build a disposable self-service path for a claims-review API. The input is a team-owned request for a repository, workload identity, namespace, and database. Acceptance requires a usable first deployment, verified support ownership, bounded privilege, a recoverable partial failure, and a cleanup disposition for every created resource. Use local fakes or disposable provider accounts; do not run the drill against shared production infrastructure.

Define the request boundary

Give each request a durable ID, caller identity, stable service ID, data classification, region, quota, cost center, lease expiry, and idempotency key. Validate ownership and policy on the server. Submit the same request twice after a simulated client timeout and prove only one set of resources exists. Submit a different specification under the same key and require a conflict. Show the requester the accepted state separately from the ready state and preserve a reason for denial without exposing credentials.

Recover partial progress

Persist step transitions and provider identifiers. After the database create is accepted, discard its response, restart the worker, and recover by looking up the intended provider identity. Fail a later deployment binding and verify the database remains inventoried under a bounded retention decision. Cancel another request while a call is in flight; do not report cleanup until the call settles and the resource is found or proved absent. A passing first deployment and an application connection test are required for Ready.

Claims platform acceptance
Request: one durable ID and one resource set after retries
Policy: caller, team, data class, region, quota checked
Execution: step state and provider IDs recoverable
Privileges: action-specific short-lived credentials
Catalog: reachable owner, rota, runbook, dependencies
Upgrade: modified generated file yields review conflict
Shared API: failed first cohort stops later consumers
Cleanup: every expired lease has verified disposition
Outcome: first deployment succeeds without manual rescue

Test the consumer lifecycle

Register the resulting service with an active team, paging rota, runbook, and declared database dependency. Disable the rota and verify the catalog check fails. Add an observed undeclared call and give its edge an owner and evidence window. Create a second repository from an older template version, customize its CI permissions, and run an upgrade proposal; require a review conflict rather than replacing that file. Attempt to invoke the provisioning action for an unauthorized team, then inspect server-side denial and log redaction.

Promote and measure

Give the database API two revisions. Inventory its consumers, promote one disposable claim, then a small production-like cohort; force a failure and prove later claims remain on their previous revision. Report each claim's observed revision, provider state, and application connection result. Calculate accepted-to-first-deploy completion, tail latency, manual interventions, stuck requests, and expired leases with live billable resources. Count rescued requests as automation failures. Deliver a resource inventory and a cleanup record that another operator can audit.

Common Mistakes

Do not infer readiness from the template task finishing.
Do not retry uncertain provider calls without reconciling existing resources.
Do not mark a generated service upgraded before its owner reviews and deploys the change.

Connected lessons

devops

project