7 min read • Guide 104 of 877
Coordinating Deployments Across Teams
Modern deployments often span multiple services, teams, and repositories. Uncoordinated deployments lead to integration failures, downtime, and finger-pointing. GitScrum helps coordinate deployment activities so everyone knows what's deploying, when, and what dependencies exist.
Deployment Challenges
| Challenge | Risk | Solution |
|---|---|---|
| Service dependencies | Broken integrations | Deployment order plan |
| Timing misalignment | Partial deploys | Coordinated schedule |
| Unknown changes | Debugging difficulty | Release notes |
| No rollback plan | Extended downtime | Documented rollback |
| Communication gaps | Teams unaware | Clear notifications |
Deployment Coordination Model
Release Train Approach
RELEASE TRAIN STRUCTURE
═══════════════════════
RELEASE: v2.5.0 (March 20, 2024)
├── Release Manager: @sarah
├── Deploy Window: 2:00-4:00 PM UTC
└── Rollback Window: Until 6:00 PM UTC
INCLUDED SERVICES:
┌─────────────────────────────────────────────────────────┐
│ Service │ Version │ Team │ Dependencies │
├─────────────────────────────────────────────────────────┤
│ API Gateway │ 1.8.0 │ Infra │ None (first) │
│ Auth Service │ 2.3.0 │ Backend │ API Gateway │
│ User Service │ 3.1.0 │ Backend │ Auth Service │
│ Web Frontend │ 4.5.0 │ Frontend│ All backends │
│ Mobile Backend │ 2.0.0 │ Mobile │ User Service │
└─────────────────────────────────────────────────────────┘
DEPLOYMENT ORDER:
1. API Gateway (2:00 PM)
2. Auth Service (2:10 PM)
3. User Service (2:20 PM)
4. Mobile Backend (2:30 PM)
5. Web Frontend (2:40 PM)
Dependency Visualization
DEPLOYMENT DEPENDENCY GRAPH
═══════════════════════════
┌─────────────────┐
│ API Gateway │
│ (Deploy 1st) │
└────────┬────────┘
│
┌────────┴────────┐
▼ ▼
┌─────────┐ ┌───────────┐
│ Auth │ │ Logging │
│ Service │ │ Service │
└────┬────┘ └───────────┘
│
┌────┴────┐
▼ ▼
┌─────────┐ ┌─────────────┐
│ User │────▶│ Mobile │
│ Service │ │ Backend │
└────┬────┘ └─────────────┘
│
▼
┌─────────────┐
│ Web │
│ Frontend │
│ (Deploy Last)│
└─────────────┘
Pre-Deployment Checklist
Readiness Verification
PRE-DEPLOYMENT CHECKLIST
════════════════════════
EACH TEAM CONFIRMS:
[API Gateway Team]
- [x] All PRs merged to release branch
- [x] Tests passing in CI
- [x] Staging tested and verified
- [x] Database migrations ready
- [x] Config changes documented
- [x] Rollback procedure documented
- [x] On-call engineer identified
Status: READY ✓
[Auth Service Team]
- [x] All PRs merged to release branch
- [x] Tests passing in CI
- [ ] Staging tested and verified ⚠
- [x] Database migrations ready
- [x] Config changes documented
- [x] Rollback procedure documented
- [x] On-call engineer identified
Status: BLOCKED - Staging verification pending
[User Service Team]
...
Go/No-Go Meeting
GO/NO-GO CHECKLIST
══════════════════
MEETING: 1:30 PM UTC (30 min before deploy)
ATTENDEES: Release manager + team leads
CHECKLIST:
├── All services show READY status?
├── All staging verifications complete?
├── All on-call engineers available?
├── Communication channels ready?
├── Monitoring dashboards open?
├── Customer support informed?
├── Rollback scripts tested?
└── Deploy scripts ready?
DECISION:
├── GO: Proceed with deployment
├── NO-GO: Abort, reschedule
└── PARTIAL: Deploy subset (with plan)
Deployment Execution
Communication Flow
DEPLOYMENT COMMUNICATION
════════════════════════
CHANNEL: #release-2.5.0
T-30 min:
├── @channel: Go/No-Go meeting starting
└── Decision: GO ✓
T-0 (2:00 PM):
├── @channel: 🚀 Deployment starting
├── @infra: Starting API Gateway deploy
└── Status: In Progress
T+10 min:
├── @infra: ✓ API Gateway deployed, smoke tests passing
├── @backend: Starting Auth Service deploy
└── Status: API Gateway ✓, Auth In Progress
T+20 min:
├── @backend: ✓ Auth Service deployed
├── @backend: Starting User Service deploy
└── Status: API ✓, Auth ✓, User In Progress
... (continue for each service)
T+45 min:
├── @channel: ✓ All services deployed
├── @channel: Running final verification
└── Status: Verification In Progress
T+50 min:
├── @channel: ✅ Release v2.5.0 complete
├── All smoke tests passing
├── Monitoring looks good
└── Status: SUCCESS
Real-Time Dashboard
DEPLOYMENT DASHBOARD
════════════════════
Release: v2.5.0 | Started: 2:00 PM | Status: IN PROGRESS
┌─────────────────────────────────────────────────────────┐
│ Service │ Status │ Time │ Health │
├─────────────────────────────────────────────────────────┤
│ API Gateway │ ✓ Complete │ 8 min │ ✓ Healthy │
│ Auth Service │ ✓ Complete │ 7 min │ ✓ Healthy │
│ User Service │ ⏳ Deploying│ 3 min │ ⏳ Pending │
│ Mobile Backend │ ⏸ Waiting │ - │ - │
│ Web Frontend │ ⏸ Waiting │ - │ - │
└─────────────────────────────────────────────────────────┘
Logs | Metrics | Rollback
CURRENT ACTIVITY:
├── User Service: Rolling update 3/5 pods
├── Waiting: Mobile Backend, Web Frontend
└── ETA: 15 minutes remaining
Rollback Procedures
Rollback Plan
ROLLBACK PROCEDURES
═══════════════════
ROLLBACK TRIGGERS:
├── Error rate > 1% for 2 minutes
├── P99 latency > 2x baseline
├── Critical functionality broken
├── Data integrity issue detected
└── Team lead decision
ROLLBACK ORDER (reverse of deploy):
1. Web Frontend → v4.4.0
2. Mobile Backend → v1.9.0
3. User Service → v3.0.0
4. Auth Service → v2.2.0
5. API Gateway → v1.7.0
SERVICE-SPECIFIC:
──────────────────────────────────────
API Gateway:
Command: kubectl rollout undo deployment/api-gateway
Verify: curl https://api/health
Time: ~2 min
Auth Service:
Command: kubectl rollout undo deployment/auth
Verify: curl https://auth/health
Time: ~2 min
Database: No migration rollback needed
──────────────────────────────────────
Partial Rollback
PARTIAL ROLLBACK SCENARIO
═════════════════════════
SITUATION: User Service causing errors
DECISION: Roll back User Service, keep others
ACTIONS:
1. Stop further deployments
2. Roll back User Service
3. Verify Auth Service still works
4. Verify API Gateway still works
5. Communicate status
POST-ROLLBACK:
├── Document what failed
├── Fix and re-test
├── Schedule new deployment
└── Post-mortem if needed
GitScrum Release Tracking
Release Task Structure
RELEASE TASK IN GITSCRUM
════════════════════════
PARENT: Release v2.5.0
├── Due: March 20, 2024
├── Owner: Release Manager
├── Labels: release, production
└── Milestone: Q1 2024 Release
CHILD TASKS:
├── [Infra] API Gateway v1.8.0
├── [Backend] Auth Service v2.3.0
├── [Backend] User Service v3.1.0
├── [Frontend] Web Frontend v4.5.0
├── [Mobile] Mobile Backend v2.0.0
├── [QA] Pre-release verification
├── [Ops] Deployment execution
└── [Ops] Post-deployment monitoring
CHECKLIST ON PARENT:
├── [ ] All services verified in staging
├── [ ] Go/No-Go meeting complete
├── [ ] All teams confirmed ready
├── [ ] Deploy complete
├── [ ] Smoke tests passing
├── [ ] Monitoring verified
└── [ ] Release notes published
Best Practices
For Deployment Coordination
- Single source of truth — One place for deploy status
- Clear ownership — Release manager drives
- Defined order — Dependencies respected
- Communication rhythm — Updates at each milestone
- Rollback ready — Always have a plan B
Anti-Patterns
DEPLOYMENT COORDINATION MISTAKES:
✗ Teams deploy independently
✗ No dependency order
✗ Silent deploys (no communication)
✗ No rollback plan
✗ Skipping go/no-go check
✗ No post-deploy verification
✗ Hero deploys (one person does everything)