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-1Step 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:
- Step 1: Current main deployment (v1.0) is running and receiving traffic
- Step 2: Deploy new version (v1.1) to same cluster
- Step 3: Test v1.1 using preview URL
- Step 4: Mark v1.1 as main - traffic switches instantly
- 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 failoverDNS 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.comOnly routes to main deployment
Preview URL
https://api-abc123.example.comUnique URL for testing this specific deployment
Internal Service
http://api-service.production.svc.cluster.local:80For internal cluster communication
Load Balancer
https://abc123-1234567890.us-east-1.elb.amazonaws.comDirect 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. Navigate to Deployments list
- 2. Find the previous stable version (still running)
- 3. Click "Mark as Main"
- 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. Click "Deploy"
- 2. Specify previous commit/tag/version
- 3. Wait for deployment to complete
- 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 requestsBest 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