Deployments

A deployment is triggered every time you push code to a repository connected to DevRamps. The system builds your artifacts, then deploys stage by stage until all stages are complete (or a failure occurs).

Deployment Lifecycle

Git Push
   │
   ▼
┌─────────────────┐
│ Pipeline         │  DevRamps reads your pipeline.yaml
│ Synthesis        │  and validates the configuration.
└────────┬────────┘
         │
         ▼
┌─────────────────┐
│ Artifact Builds  │  Docker images and bundles are built
│                  │  (if source files changed).
└────────┬────────┘
         │
         ▼
┌─────────────────┐
│ Stage: staging   │  Steps execute in order.
│                  │  Artifacts are mirrored to target account.
└────────┬────────┘
         │ (auto-promote)
         ▼
┌─────────────────┐
│ Stage: prod      │  Same steps, different account/region.
└─────────────────┘

Pipeline synthesis

When a push is received, DevRamps reads your pipeline.yaml and creates a deployment plan. It resolves expressions (except secrets and step outputs, which are deferred), validates the configuration, and determines which artifacts need rebuilding.

Artifact builds

Artifacts are built in parallel in isolated VMs. If rebuild_when_changed paths haven't changed since the last successful build, the artifact is reused -- saving time and compute.

Stage execution

Each stage runs through a set of internal phases:

1. Resource validation -- Verifies that required AWS resources (ECR repos, S3 buckets) exist.
2. Artifact mirroring -- Copies artifacts from the CI/CD account to the stage's target account/region.
3. Infrastructure synthesis -- Runs Terraform (if configured), with optional approval.
4. Deployment steps -- Runs your deployment steps in order.

Stage promotion

When a stage completes successfully, the next stage starts automatically. There's no manual promotion step unless you've configured approval gates or deployment time windows.

Triggering Deployments

Deployments are triggered by GitHub push webhook events. When you push code to a connected repository, DevRamps checks each pipeline's tracked branch and starts a deployment only if the push matches.

By default, pipelines track main. You can change this with the tracks field in your pipeline.yaml. See Branch Tracking for details.

Branch filtering

Only pushes to a pipeline's tracked branch trigger deployments. For example, if your pipeline has tracks: main, pushing to a feature branch does not trigger a deployment.

DevRamps processes one deployment at a time per stage. If you push again while a deployment is in progress, the new deployment queues and starts after the current one finishes.

Deployment Locking

Each stage has a deployment lock that prevents concurrent deployments:

• When a deployment starts in a stage, the stage is locked.
• If a new push arrives while the stage is locked, the new deployment queues.
• When the current deployment finishes, the lock is released and the queued deployment starts.
• Only the most recent queued commit deploys -- intermediate commits are skipped. Artifacts for skipped intermediate commits are not built.

This ensures deployments don't interfere with each other and that your latest code always gets deployed.

Revisions

Each deployment is assigned a sequential revision number. Revisions are used to:

• Track deployment history.
• Reference specific deployments for rollback.
• Identify which version of your code is running in each stage.

You can view revision history in the DevRamps dashboard or via the API.

Deployment States

Each stage in a deployment can be in one of these states:

State	Description
Not Started	The stage hasn't begun yet (waiting for a previous stage).
In Progress	Steps are actively executing.
Succeeded	All steps completed successfully.
Failed	A step failed. The deployment stopped.
Cancelled	The deployment was manually cancelled.
Cancelling	A cancellation was requested and is in progress.
Rolling Back	An emergency rollback is in progress.
Rolled Back	The rollback completed successfully.
Rolling Forward	An emergency roll-forward is in progress.
Rolled Forward	The roll-forward completed successfully.
Timed Out	The deployment exceeded the timeout. Individual step timeouts are configurable via the timeout parameter on each step.

What Happens on Failure

When a step fails:

1. The deployment stops at the failed step. Remaining steps in the stage are skipped.
2. The next stage does not start.
3. The stage is marked as Failed.
4. You can view step logs to diagnose the issue.
5. Options:
   • Fix and push: Fix the issue in code and push again. A new deployment starts.
   • Retry the stage: Re-run the failed stage with the same code. See Retry a Failed Stage.
   • Rollback: Deploy a previous revision. See Emergency Rollback.
   • AI analysis: Use the AI agent to analyze the failure and suggest a fix.