Multi-Team Deployments | Release Coordination

Coordinate multi-service deployments: define deployment order, dependencies, timing, and rollback plans. GitScrum tracks releases and notifies all teams.

7 min read

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)