Production-grade guide to deployment strategy comparison covering architecture patterns, implementation strategies, testing approaches, and operational best practices for enterprise engineering teams.
Deployment strategy comparison is a guide to selecting the right approach for rolling out code to production, based on risk tolerance, team size, infrastructure maturity, and release cadence. It is used when a team must balance speed of delivery against reliability, and when the cost of a failed deployment—whether in downtime, degraded performance, or data loss—outweighs the effort of setting up a more sophisticated process.
When releasing once per quarter, a team can afford to plan meticulously and deploy with full manual oversight. But as release frequency increases—daily, multiple times per day, or even continuous—the need for automation, monitoring, and incremental rollout becomes critical. The choice of strategy depends on how often code is shipped and how much disruption is acceptable between releases.
For infrequent releases (weekly or less), blue-green deployment is the most predictable. The current production environment (the *blue* environment) runs the latest stable version. A new version is deployed to a parallel environment (*green*), configured identically and running the same load balancer. Once testing is complete, the load balancer redirects all traffic to the green environment. The process is initiated by a simple script:
kubectl apply -f manifests/green-deployment.yaml
kubectl rollout status deployment/app-green -n production
# Validate green environment
curl -s http://green-app.example.com/health | jq .status
# Switch traffic via load balancer
kubectl patch service/app-lb -n production -p '{
"spec": {
"selector": {
"app": "app-green"
}
}
}'The key failure mode in blue-green is data consistency. If the green environment is updated during the release, and the old blue environment continues to write to the shared database, data changes may be lost or overwritten. To mitigate this, teams often use database migration scripts that are applied during the cutover window:
-- Apply migration during cutover
BEGIN;
-- Update schema
ALTER TABLE users ADD COLUMN email_verified BOOLEAN DEFAULT FALSE;
-- Migrate data
UPDATE users SET email_verified = true WHERE verified_at IS NOT NULL;
-- Finalize migration
COMMIT;The script must be idempotent and atomic. If the cutover fails, the blue environment must be restored quickly. A common mistake is to forget to rollback the load balancer in case of failure, leaving traffic on the green environment with a broken app.
Teams with high risk tolerance—where downtime is acceptable and can be communicated in advance—may prefer rolling deployments. This strategy updates a subset of instances at a time, gradually replacing the old version across the entire fleet.
A rolling deployment is configured with kubectl using the strategy field in a Deployment manifest:
apiVersion: apps/v1
kind: Deployment
metadata:
name: app
namespace: production
spec:
replicas: 10
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 2
maxUnavailable: 1
selector:
matchLabels:
app: app
template:
metadata:
labels:
app: app
spec:
containers:
- name: app
image: registry.example.com/app:v1.2.3With maxSururge: 2, the system can create up to two extra pods during the update, ensuring no downtime. maxUnavailable: 1 allows one pod to be unavailable while the rest serve traffic.
The process is monitored via kubectl rollout status:
kubectl rollout status deployment/app -n production --watchThis command blocks until the rollout completes, and it fails if any pod fails health checks. The default health check is a readiness probe:
readinessProbe:
httpGet:
path: /health
port: 8080
initialDelaySeconds: 10
periodSeconds: 5
timeoutSeconds: 3A common failure is health checks that are too aggressive. If the probe expects the application to respond within 3 seconds, but the startup phase takes 5 seconds, the pod is marked ready before the database connection is established. This leads to 500 errors during the rollout.
To address this, teams add a liveness probe that ensures the pod is still alive:
livenessProbe:
httpGet:
path: /ready
port: 8080
initialDelaySeconds: 30
periodSeconds: 10The liveness probe checks a /ready endpoint that returns 200 only when all dependencies are ready. This separates startup from runtime health.
For smaller teams or early-stage projects, canary deployment offers a middle ground: it allows testing a new version on a subset of users while the rest continue on the stable version.
A canary deployment begins with a base deployment of the current version, then adds a second version to a small fraction of nodes. Traffic is routed to the canary based on a routing rule, often implemented via a traffic-splitting service like Istio or a simple load balancer configuration.
# Istio VirtualService for canary
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: app
namespace: production
spec:
hosts:
- app.example.com
http:
- route:
- destination:
host: app
subset: stable
weight: 90
- destination:
host: app
subset: canary
weight: 10After deployment, the team monitors metrics—latency, error rates, and request volume—over a 24-hour period. If the canary performs well, they increase the traffic split in stages:
# Increase canary to 30%
- route:
- destination:
host: app
subset: stable
weight: 70
- destination:
host: app
subset: canary
weight: 30The critical failure mode in canary deployment is inconsistent state across canary and stable versions. If the canary version uses a different database schema or cache format, users may experience data inconsistencies. To detect this, teams often run feature flag comparisons:
# Feature flag to enable canary-only behavior
if (user.id in canary_users) {
use_new_user_profile_api();
} else {
use_old_user_profile_api();
}A subtle but common issue is delayed canary promotion. A deployment may be marked successful based on metrics from the first 2 hours, but after 24 hours, the canary begins to show increased latency. The team must have automated rollback based on sustained metrics:
# Rollback canary if error rate exceeds 1%
if (error_rate > 0.01) {
kubectl apply -f manifests/rollback-canary.yaml
kubectl patch virtualservice app -n production -p '{
"spec": {
"http": [
{
"route": [
{
"destination": {
"host": "app",
"subset": "stable"
},
"weight": 100
}
]
}
]
}
}'
}The rollback logic must be idempotent and monitorable. Teams often use Prometheus to define alert rules:
groups:
- name: canary-deployment
rules:
- alert: CanaryErrorRateHigh
expr: rate(app_error_total{job="app-canary"}[5m]) > 0.01
for: 1h
labels:
severity: warning
annotations:
summary: "Canary error rate above 1% for 1 hour"For highly mature infrastructure, dark launch and progressive delivery strategies allow teams to deploy new features without exposing them to users, enabling rigorous testing before rollout.
In a dark launch, a new version of the application is deployed and running in production, but traffic is not routed to it. The new version processes requests in the background—logging, caching, and preparing for production—but users continue to see the old version.
To enable a dark launch, teams use feature flags that control whether a new component is active:
# Feature flag configuration
feature_flags:
new_checkout_flow:
enabled: false
rollout_percentage: 0
rollout_strategy: "all-users"
conditions:
- user_segment: "premium"
percentage: 50
- region: "us-west"
percentage: 75When the team is ready, they enable the flag and gradually increase the rollout percentage:
# Enable new checkout flow for all users
curl -X PUT http://config-service.example.com/flags/new_checkout_flow \
-d '{"enabled": true, "rollout_percentage": 100}'The key challenge in dark launch is data consistency between old and new systems. If the new checkout flow writes to a different database or uses a different schema, the team must ensure that the new system can read from the old and vice versa. A common failure is duplicate orders—when users submit a checkout form and the new system processes it, but the old system also processes it due to delayed synchronization.
To detect this, teams use dual-write patterns:
func submitOrder(order Order) error {
// Write to both old and new systems
if err := oldOrderService.Create(order); err != nil {
return err
}
if err := newOrderService.Create(order); err != nil {
return err
}
// Signal completion
go notifyNewSystem(order.ID)
return nil
}As the system stabilizes, teams transition to progressive delivery, where features are rolled out in stages—first to a small group, then to 10%, then to 50%, and finally to 100%. This allows fine-grained control and feedback.
kubectl get nodes and kubectl get svc in deployment scripts to detect misconfigurations.In summary, deployment strategy selection is not a one-time decision. It is a continuous practice of aligning release cadence, risk tolerance, team size, and infrastructure maturity with the right combination of techniques. The goal is not just to deploy code, but to ship value with confidence.
This page was rewritten on 15 October 2026. It replaced a templated version that was not specific to its own title. How these pages are written and checked. If anything here is wrong, tell us at [email protected] and we will correct it.
We use cookies for analytics (Google Analytics) and advertising (Google AdSense) to improve your experience and support free content. Privacy Policy