intrnl.cloud
Operations

Deploy and roll back

Operator procedure for approved immutable deployments and schema-aware artifact rollback.
Procedure specification — not yet operationally validated. Before pilot use, the operations owner must attach exact console/API/CLI actions, environment identifiers, access requirements, escalation contacts, and rehearsal evidence. No platform command names or completed drills are implied here.

Preconditions

The requester, approver, organization, app, and target environment are identified. The exact source revision, artifact digest, runtime contract, policy, capability changes, and migration analysis are recorded. Required human approvals are current. The runtime cluster is healthy, backups are usable, and a prior healthy artifact is identifiable.

Deploy

  1. Reauthorize the request and revalidate approval against the exact artifact, source, migration set, capability set, and material policy. Stop if any changed after approval.
  2. Verify the artifact signature and digests through trusted platform services before executing it. Confirm that the cluster supports the pinned contract.
  3. Confirm the isolated synthetic preview and required tests succeeded. Review application-level authorization as well as gateway access.
  4. Acquire the environment migration lock. Create and verify the pre-migration snapshot before applying unapplied, checksum-verified migrations.
  5. Apply migrations and validate schema. On failure, stop activation and assess compatibility with the serving revision. An unchanged route does not reverse database changes.
  6. Start the verified candidate sandbox and initialize scoped bindings. Run readiness and request smoke checks.
  7. Atomically change the route only after readiness passes. Drain the previous workload and retain it for the rollback window.
  8. Verify Entra access, authorized workflow behavior, telemetry, and audit attribution. Record the active deployment and health result.

Failure handling

A failed signature, binding, or health check must prevent route activation. An incompatible migration requires incident handling and a reviewed recovery decision. Do not automatically restore a production database when an artifact fails. Retry orchestration using the existing command/idempotency identity rather than creating duplicate transitions.

Artifact rollback

  1. Select a prior healthy deployment by immutable ID/digest.
  2. Confirm that it can operate with the current schema and bindings. Stop for human review if compatibility is unknown.
  3. Reauthorize rollback and verify the prior signed artifact; start or re-enable its workload.
  4. Run health checks, switch the route atomically, and drain the failing revision.
  5. Verify representative user operations and audit the requester, target revision, reason, and outcome.

Completion evidence

Capture source and artifact identities, approval record, migration/snapshot IDs, readiness result, old/new route versions, actor, timestamps, and redacted smoke-test evidence. Database restore is a separate action in the backup and restore runbook.