WPHammer
Log in

Deployment Tracking

Every pipeline operation creates a Deployment record that tracks who triggered it, which site it affects, and exactly what happened at each step. You can monitor active deployments in real time and review completed ones later.

Deployment record

Each deployment stores:

Field Description
team_id The team that owns the deployment
user_id The user who triggered it
site_id The target site
type The pipeline type (e.g., create_site, clone_site)
status Current status from the DeploymentStatus enum
operation_name Human-readable name for the operation
meta JSON metadata with pipeline-specific context (staging ID, capsule ID, etc.)
started_at When the first step began
finished_at When the deployment completed, failed, or was cancelled

Deployments use ULIDs as primary keys for sortable, unique identifiers.

Deployment statuses

The DeploymentStatus enum tracks the overall lifecycle:

  • Queued — the deployment has been created but no steps have started
  • Running — at least one step is actively executing
  • Completed — all steps finished successfully
  • Failed — a step encountered an error, halting the pipeline
  • Cancelled — the deployment was manually cancelled before completion

The isFinished() method returns true for Completed, Failed, and Cancelled — useful for filtering active vs. historical deployments.

Step tracking

Each DeploymentStep record captures granular detail:

Field Description
name Step name (e.g., "Create database & user")
status Step-level status from the StepStatus enum
sort_order Execution order within the pipeline
output Text output from the step's execution
started_at When the step began
finished_at When it completed or failed

Step output captures command results, error messages, and diagnostic information. When a step fails, the output contains the error details needed to diagnose the issue.

Real-time updates

Both Deployment and DeploymentStep models use Laravel's BroadcastsEvents trait. As each step transitions through its lifecycle, events are broadcast to the frontend. The UI reflects step progress without requiring page refreshes — you see each step start, complete, or fail as it happens.

Meta context

The meta JSON field carries pipeline-specific data that steps need to do their work. For example:

  • Clone pipelines store the source site ID and server details
  • Staging pipelines store the staging_id linking to the staging environment
  • Time capsule pipelines store the capsule_id for the archive being created or restored
  • Restore pipelines store the backup or restore point reference

Each step's job receives the full deployment record and can read from meta to resolve its inputs.

Viewing history

Deployments are scoped to a team and optionally filtered by site. The deployment list shows:

  • The operation name and pipeline type
  • Who triggered it and when
  • Current status with color coding
  • Step-by-step progress for active deployments
  • Duration from start to finish for completed ones

Failed deployments preserve the full step trail, including the failing step's output, so you can diagnose issues without digging through logs.

Cancelling deployments

A running deployment can be cancelled, which sets its status to Cancelled. Any queued steps that have not yet started are left in their Queued state. Steps that have already completed retain their Completed status. Only the currently running step (if any) is affected by cancellation.

Related