Deployments

Deployment Overview

Deployments in the Riven Platform are managed through Helm releases combined with Argo Rollouts for advanced deployment strategies. Every deployment is tracked, versioned, and auditable — giving your team full visibility into what is running and when it changed.

You can trigger deployments through the Platform dashboard, the Riven CLI, or automatically via the CI/CD pipeline when changes are merged to the main branch.

Creating a Deployment

To create a new deployment, use the Riven CLI. The CLI handles image selection, environment configuration, and Helm upgrade execution.

# Deploy a new service for the first time
riven dev-center service deploy my-service \
  --tag 1.2.3-de54b1c \
  --repo-type js \
  --image-repository <account-id>.dkr.ecr.us-east-1.amazonaws.com/my-service
 
# Roll out a new version of an existing service
riven dev-center rollout start my-service 1.2.4-abc1234
 
# Check rollout status
riven dev-center rollout status my-service

The dashboard provides a visual deployment wizard that handles image selection, environment configuration, and approval workflows without needing to touch the CLI.

Image Tagging

All deployment images must follow the <semver>-<short-sha> format. This ensures every image is traceable back to a specific commit.

# Read version from package.json and append git short SHA
VERSION=$(node -p "require('./package.json').version")
SHA=$(git rev-parse --short HEAD)
TAG="${VERSION}-${SHA}"
# Result: 1.2.3-de54b1c

Rollback

If a deployment causes issues, you can roll back to any previous revision instantly. The Platform maintains a complete history of Helm releases, making it easy to identify and revert to a known-good state.

# View release history
helm history my-service -n dev-center
 
# Rollback to a specific revision
helm rollback my-service 3 -n dev-center
 
# Verify rollback
kubectl get pods -n dev-center -l app=my-service

Rollback Decision Tree

Use this guide to determine the right recovery action when a deployment fails:

1. Pods not starting (CrashLoopBackOff)

   • Check logs: kubectl logs <pod> -n dev-center --previous
   • Common cause: missing env vars, bad config, OOM
   • Action: Fix config and redeploy, or rollback to previous revision

2. Pods running but errors in traffic

   • Check error rate in Grafana or riven dev-center rollout status <name>
   • Action: If error rate > 5%, rollback immediately

3. Deployment stuck (not progressing)

   • Check events: kubectl describe deployment <name> -n dev-center
   • Common cause: insufficient resources, image pull failures
   • Action: Scale down other workloads or fix image reference

4. Post-rollback verification

   • Confirm pods are healthy: kubectl get pods -l app=<name> -n dev-center
   • Confirm traffic is clean: check Grafana error rate dashboard
   • Notify team in Slack with rollback details

Failed Deployment Recovery

When a deployment fails and automatic rollback does not trigger:

# 1. Check what went wrong
kubectl get events -n dev-center --sort-by=.lastTimestamp | tail -20
kubectl describe deployment my-service -n dev-center
 
# 2. Force rollback to last known good revision
helm rollback my-service 0 -n dev-center  # 0 = previous revision
 
# 3. Verify recovery
kubectl rollout status deployment/my-service -n dev-center
riven dev-center rollout status my-service
 
# 4. If Helm state is corrupted, delete and redeploy
helm uninstall my-service -n dev-center
riven dev-center service deploy my-service \
  --tag <last-good-tag> \
  --repo-type js \
  --image-repository <ecr-repo>

Blue-Green Deployments

For zero-downtime releases, the Platform supports blue-green and canary deployment strategies through Argo Rollouts. These strategies allow you to gradually shift traffic to the new version while monitoring for errors.

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: my-service
spec:
  strategy:
    blueGreen:
      activeService: my-service-active
      previewService: my-service-preview
      autoPromotionEnabled: false
      scaleDownDelaySeconds: 30

With canary deployments, you can route a percentage of traffic to the new version, monitor key metrics, and automatically promote or roll back based on success criteria.

Deployment History

Every deployment is recorded in an audit log with details including the deployer, image tag, environment, timestamp, and outcome. The deployment history provides a complete timeline of changes for each service.

• Timeline view — Chronological list of all deployments with status indicators and diff links.
• Comparison — Side-by-side comparison of configuration changes between any two revisions.
• Audit trail — Full audit log with who deployed what, when, and the approval chain.