SEAGIT DOCS
Deployments

Deployments

Manage application releases, track versions, and control deployment lifecycle with real-time monitoring and rollback capabilities.

What is a Deployment?

A deployment is an individual release of an application instance to one or more Kubernetes clusters. Each deployment represents a specific version of your application (commit, tag, or chart version) running in your environment.

KEY CONCEPTS:

  • Version Tracking: Each deployment is tied to a specific commit, tag, or chart version
  • Lifecycle Management: Control deployment state from creation to termination
  • Multi-Cluster: Deploy to multiple clusters simultaneously
  • Rollback Capability: Quickly revert to previous versions
  • Real-time Monitoring: View logs, events, and status updates

Deployment Lifecycle

Every deployment progresses through a series of states:

1. Created / Queued

Deployment request received and queued for processing. Initial state after clicking "Deploy".

2. Starting

SeaGit is provisioning resources, pulling images, and creating Kubernetes objects. Build process runs if deploying from source code.

3. Started (Running)

Application is successfully running and healthy. All pods are ready and passing health checks.

4. Stopping

Graceful shutdown in progress. Pods are being drained and terminated.

5. Stopped

All resources are scaled to zero. Configuration preserved, can be restarted without redeployment.

6. Terminating

Permanent removal in progress. All Kubernetes resources being deleted.

7. Terminated

Deployment completely removed. All resources cleaned up. Can only be redeployed, not restarted.

Error States:

  • Start Error: Failed to start (image pull errors, configuration issues)
  • Stop Error: Failed to stop gracefully
  • Terminate Error: Failed to clean up resources
  • Cancelled: Deployment cancelled by user during startup

Creating a Deployment

Step 1: Navigate to Application Instance

Go to Applications → Select your application → Select an instance

Step 2: Click "Deploy"

The deploy dialog will open with configuration options.

Step 3: Select Target Clusters

Choose one or more clusters from the environment. You can deploy to multiple clusters simultaneously for high availability.

☑ production-us-east-1
☑ production-us-west-2
☐ production-eu-west-1

Step 4: Specify Version

  • Git Source: Branch, commit hash, or tag (e.g., main, abc123, v1.2.3)
  • Container: Image tag (e.g., latest, v1.2.3, sha-abc123)
  • Helm Chart: Chart version (e.g., 1.2.3)

Step 5: Review and Deploy

Review configuration and click Deploy. Monitor progress in real-time.

Deployment Operations

Deploy

Create a new deployment of your application to selected clusters.

Availability: Anytime

Stop

Scale deployment to zero replicas. Resources preserved for quick restart.

Availability: When running

Start

Restart a stopped deployment. Scales back to configured replica count.

Availability: When stopped

Terminate

Permanently remove deployment and all associated resources.

Availability: When stopped

Delete

Remove deployment record from SeaGit (metadata only).

Availability: When terminated

Cancel

Abort deployment during startup phase before it becomes active.

Availability: During starting

Mark as Main

Designate this deployment as the production version for traffic routing.

Availability: When running

Redeploy

Create new deployment with same version (useful for configuration changes).

Availability: Anytime

Main Deployment

The main deployment is the designated production version of your application. It receives traffic from your domain and is highlighted in the UI.

Blue-Green Deployment Pattern:

  1. Step 1: Current main deployment (v1.0) is running and receiving traffic
  2. Step 2: Deploy new version (v1.1) to same cluster
  3. Step 3: Test v1.1 using preview URL
  4. Step 4: Mark v1.1 as main - traffic switches instantly
  5. Step 5: Keep v1.0 running as backup, terminate when confident

This pattern enables zero-downtime deployments with instant rollback capability.

Multi-Cluster Deployments

Deploy to multiple clusters for high availability, disaster recovery, and multi-region performance.

Use Cases

  • High Availability: Multiple availability zones within a region
  • Disaster Recovery: Multiple regions for business continuity
  • Global Performance: Deploy closer to users worldwide
  • Load Distribution: Distribute traffic across clusters

Configuration

When creating a deployment, select multiple target clusters:

✓ us-east-1-prod (Primary)
✓ us-west-2-prod (Secondary)
✓ eu-west-1-prod (Secondary)

Traffic routing: Latency-based with health check failover

DNS Routing Policies

  • Simple: Single cluster receives all traffic
  • Latency-based: Route to nearest healthy cluster
  • Failover: Primary cluster with automatic failover to secondary
  • Weighted: Distribute traffic by percentage across clusters

Deployment Logs

SeaGit provides comprehensive real-time logging for all deployment phases:

Build Logs

For Git source deployments, view buildpack detection, dependency installation, and compilation output.

Container Logs

Real-time stdout/stderr from your application containers. Automatically streams as pods start.

Kubernetes Events

Pod scheduling, image pulls, health checks, and error events from the cluster.

Log Features:

  • Live Streaming: Logs update in real-time as events occur
  • Historical: Access logs from previous deployments
  • Filtering: Filter by log level (info, warn, error)
  • Search: Full-text search across all logs
  • Download: Export logs for offline analysis

Access URLs

Each deployment receives multiple access URLs depending on configuration:

Main Domain

https://api.example.com

Only routes to main deployment

Preview URL

https://api-abc123.example.com

Unique URL for testing this specific deployment

Internal Service

http://api-service.production.svc.cluster.local:80

For internal cluster communication

Load Balancer

https://abc123-1234567890.us-east-1.elb.amazonaws.com

Direct AWS ALB/NLB endpoint

Duration Tracking

SeaGit tracks deployment timing metrics to help you optimize your CI/CD pipeline:

  • Queue Time: Time waiting for available resources
  • Build Time: Source code build duration (if applicable)
  • Image Pull Time: Container image download duration
  • Startup Time: Time for pods to become ready
  • Total Time: End-to-end deployment duration

Performance Tips:

  • Use smaller base images to reduce pull time
  • Cache dependencies in Docker layers
  • Optimize health check timing to avoid false negatives
  • Use image pull secrets for private registries to avoid auth delays

Rollback Procedures

SeaGit provides multiple strategies for rolling back to a previous version:

Method 1: Mark Previous Deployment as Main

Fastest rollback - instantly switch traffic to a previous running deployment.

  1. 1. Navigate to Deployments list
  2. 2. Find the previous stable version (still running)
  3. 3. Click "Mark as Main"
  4. 4. Traffic switches immediately (no redeploy needed)

⚡ Rollback time: ~5 seconds

Method 2: Redeploy Previous Version

If the previous deployment was terminated, create a new deployment with the old version.

  1. 1. Click "Deploy"
  2. 2. Specify previous commit/tag/version
  3. 3. Wait for deployment to complete
  4. 4. Mark as main

⏱️ Rollback time: 2-5 minutes

Emergency Rollback:

Always keep at least one previous stable deployment in "Stopped" state (not terminated) for 24-48 hours after a new release. This allows instant rollback using Method 1.

Troubleshooting

ImagePullBackOff

Symptom: Deployment stuck in "Starting" state, logs show image pull errors

Causes:

  • • Image does not exist or tag is incorrect
  • • Private registry requires authentication
  • • Network connectivity issues to registry
  • • Rate limiting from Docker Hub (pull quota exceeded)

Solutions:

  • • Verify image name and tag are correct
  • • Add Docker registry provider with credentials
  • • Use a mirror or private registry to avoid rate limits
  • • Check cluster has internet access to pull images

CrashLoopBackOff

Symptom: Pods repeatedly start and crash

Causes:

  • • Application code error (exceptions on startup)
  • • Missing required environment variables
  • • Cannot connect to database or external service
  • • Port already in use or misconfigured

Solutions:

  • • Check container logs for error messages
  • • Verify all required variables/secrets are set
  • • Test database connectivity and credentials
  • • Ensure application listens on correct port

OOMKilled (Out of Memory)

Symptom: Pods restart with "OOMKilled" reason

Causes:

  • • Memory limit set too low for application needs
  • • Memory leak in application code
  • • Unexpected traffic spike causing high memory usage

Solutions:

  • • Increase memory limit in application configuration
  • • Profile application to identify memory leaks
  • • Enable horizontal pod autoscaling for traffic spikes
  • • Optimize application memory usage

Deployment Pending

Symptom: Pods stuck in "Pending" state, not starting

Causes:

  • • Insufficient cluster resources (CPU/memory)
  • • No nodes match pod affinity/anti-affinity rules
  • • Persistent volume claim cannot be fulfilled

Solutions:

  • • Check cluster autoscaler is enabled and working
  • • Reduce resource requests or scale up cluster
  • • Review node selectors and taints/tolerations
  • • Verify storage class can provision volumes

Health Check Failures

Symptom: Pods restart frequently due to failed health checks

Causes:

  • • Health check endpoint returns non-200 status
  • • Application takes longer to start than health check allows
  • • Health check timeout too short for slow endpoints

Solutions:

  • • Fix health check endpoint to return 200 when healthy
  • • Increase initialDelaySeconds in health check config
  • • Increase timeout and failure threshold settings
  • • Optimize application startup time

API Reference

Manage deployments programmatically using the SeaGit API:

List Deployments

GET /api/v1/deployments?instance_id=123

Response:
{
  "deployments": [
    {
      "id": "deploy-456",
      "instance_id": "123",
      "version": "v1.2.3",
      "status": "started",
      "main": true,
      "created_at": "2024-01-15T10:30:00Z",
      "clusters": ["cluster-789"],
      "url": "https://api.example.com"
    }
  ]
}

Create Deployment

POST /api/v1/deployments

{
  "instance_id": "123",
  "version": "v1.2.4",
  "cluster_ids": ["cluster-789", "cluster-790"]
}

Response: 201 Created
{
  "id": "deploy-457",
  "status": "queued"
}

Stop Deployment

POST /api/v1/deployments/deploy-456/stop

Response: 200 OK
{
  "status": "stopping"
}

Mark as Main

POST /api/v1/deployments/deploy-457/mark-main

Response: 200 OK
{
  "main": true,
  "previous_main": "deploy-456"
}

Get Deployment Logs

GET /api/v1/deployments/deploy-456/logs?type=container

Response: 200 OK (streaming)
2024-01-15T10:30:01Z [INFO] Server started on port 3000
2024-01-15T10:30:02Z [INFO] Connected to database
2024-01-15T10:30:03Z [INFO] Ready to accept requests

Best Practices

DO:

  • ✓ Use semantic versioning for tags (v1.2.3)
  • ✓ Keep at least one previous deployment available for quick rollback
  • ✓ Test in staging environment before production
  • ✓ Monitor deployment logs during and after release
  • ✓ Use preview URLs to verify changes before marking as main
  • ✓ Implement proper health checks for accurate status
  • ✓ Set resource limits to prevent resource exhaustion
  • ✓ Use blue-green deployments for zero-downtime releases

DON'T:

  • ✗ Deploy directly to production without testing
  • ✗ Terminate old deployments immediately after release
  • ✗ Use "latest" tag in production (not reproducible)
  • ✗ Deploy during peak traffic hours
  • ✗ Skip health checks to speed up deployment
  • ✗ Set resource limits too low (causes OOMKilled)
  • ✗ Ignore failed deployments - investigate root cause
  • ✗ Deploy breaking changes without migration plan