BMAD-METHOD/src/bmm-skills/3-solutioning/bmad-create-pipeline/steps/step-04-deployment-strategy.md

Step 4: Deployment Strategy

MANDATORY EXECUTION RULES (READ FIRST):

• 🛑 NEVER generate content without user input
• 📖 CRITICAL: ALWAYS read the complete step file before taking any action - partial understanding leads to incomplete decisions
• 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read and understood before proceeding
• ✅ ALWAYS treat this as collaborative discovery between pipeline architecture peers
• 📋 YOU ARE A FACILITATOR, not a content generator
• 💬 FOCUS on deployment strategy decisions that directly impact DORA metrics
• 🌐 ALWAYS search the web to verify current technology versions
• ⚠️ ABSOLUTELY NO TIME ESTIMATES - AI development speed has fundamentally changed
• ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config {communication_language}

EXECUTION PROTOCOLS:

• 🎯 Show your analysis before taking any action
• 🌐 Search the web to verify technology versions and options
• ⚠️ Present A/P/C menu after each major decision category
• 💾 ONLY save when user chooses C (Continue)
• 📖 Update frontmatter stepsCompleted: [1, 2, 3, 4] before loading next step
• 🚫 FORBIDDEN to load next step until C is selected

COLLABORATION MENUS (A/P/C):

This step will generate content and present choices for each decision category:

• A (Advanced Elicitation): Use discovery protocols to explore innovative approaches to deployment strategies
• P (Party Mode): Bring multiple perspectives to evaluate deployment trade-offs
• C (Continue): Save the current decisions and proceed to validation

PROTOCOL INTEGRATION:

• When 'A' selected: Invoke the bmad-advanced-elicitation skill
• When 'P' selected: Invoke the bmad-party-mode skill
• PROTOCOLS always return to display this step's A/P/C menu after the A or P have completed
• User accepts/rejects protocol changes before proceeding

CONTEXT BOUNDARIES:

• Pipeline architecture decisions from step 2 are available
• Pipeline stage decisions from step 3 are available (especially deploy and promote stages)
• Infrastructure context from step 1 is available
• Focus on advanced deployment patterns, rollback, and operational resilience

DORA METRICS CONTEXT:

These decisions directly impact your deployment frequency and change failure rate. The four DORA metrics to keep in mind:

1. Deployment Frequency - How often you deploy to production
2. Lead Time for Changes - Time from commit to production
3. Change Failure Rate - Percentage of deployments causing failures
4. Mean Time to Recovery (MTTR) - How quickly you recover from failures

Reference these metrics when discussing trade-offs for each decision.

YOUR TASK:

Facilitate collaborative deployment strategy decision making, focusing on patterns that ensure safe, fast, and reliable deployments with clear rollback and recovery mechanisms.

DECISION MAKING SEQUENCE:

1. Load Context from Previous Steps

Review Deploy and Promote Stage Decisions: "Based on our pipeline stage design in step 3, let's deepen the deployment strategy:

Deploy Stage Decisions:

• Method: {{push_or_gitops_from_step_3}}
• Tool: {{deployment_tool_from_step_3}}
• Environment Sequence: {{env_progression_from_step_3}}

Promote Stage Decisions:

• Gates: {{promotion_gates_from_step_3}}
• Mechanism: {{promotion_mechanism_from_step_3}}"

2. Decision Categories

Category 1: Deployment Pattern

Options to present with trade-offs:

• Blue-Green Deployment - Two identical environments, instant switchover. Pro: zero-downtime, instant rollback. Con: 2x infrastructure cost, database state complexity
• Canary Deployment - Gradual traffic shift to new version. Pro: risk mitigation, real-world validation. Con: complexity, observability requirements, longer rollout
• Rolling Update - Gradual replacement of instances. Pro: resource efficient, built into orchestrators. Con: mixed versions during rollout, slower rollback
• Recreate - Tear down old, deploy new. Pro: simple, clean state. Con: downtime window required
• A/B Testing - Route specific users to new version. Pro: feature validation, user-segment testing. Con: routing complexity, session management

Verify Technology Versions:

Search the web: "{{deployment_tool}} {{pattern}} implementation"
Search the web: "{{pattern}} best practices {{year}}"

Category 2: Feature Flag Strategy

• LaunchDarkly - Enterprise feature management platform, rich targeting, analytics
• Unleash - Open-source feature toggle system, self-hosted or managed
• Flagsmith - Open-source, remote config and feature flags
• Custom implementation - Application-level feature flags (config-driven or database-driven)
• None - No feature flags, rely on branch/deploy strategy alone

Discuss how feature flags interact with the deployment pattern and branch strategy.

Category 3: Database Migration Coordination

• Pre-deploy migrations - Run migrations before deploying new code. Requires backward-compatible migrations
• In-deploy migrations - Migrations run as part of deployment process. Simpler but riskier
• Post-deploy migrations - Deploy code first, then migrate. Requires code that handles both schemas
• Expand-Contract pattern - Multi-phase: expand schema (additive), deploy code, contract schema (remove old). Safest for zero-downtime

Present how each approach affects rollback capability and downtime.

Category 4: Rollback Strategy

• Automated rollback - Automatically revert on failure criteria (health check failures, error rate spike, latency threshold)
• Manual rollback - Human decision to revert, with automated execution
• Hybrid - Automated for critical failures, manual for degraded performance

Sub-decisions:

• Rollback criteria (what triggers it)
• Rollback mechanism (redeploy previous version, traffic shift, infrastructure swap)
• Data rollback considerations (can database changes be reverted?)
• Rollback testing (do you regularly test rollback procedures?)

Category 5: Zero-Downtime Requirements

• Required - Application must be available during all deployments
• Maintenance window acceptable - Scheduled downtime windows for deployments
• Best effort - Minimize downtime but brief interruptions acceptable

If zero-downtime is required:

• Graceful shutdown handling (drain connections, finish in-flight requests)
• Health check integration (readiness vs liveness probes)
• Connection draining configuration
• Load balancer integration

Category 6: Multi-Region Deployment (If Applicable)

• Single region - All deployments to one region
• Active-passive - Primary region with failover region
• Active-active - Multiple regions serving traffic simultaneously

If multi-region:

• Region deployment order (canary region first?)
• Cross-region data consistency
• Regional rollback independence
• Global traffic management (Route53, CloudFront, Global Accelerator)

3. Facilitate Each Decision

For each category, follow the collaborative decision pattern from previous steps.

Record the Decision:

• Category: {{category}}
• Decision: {{user_choice}}
• DORA Impact: {{how_this_affects_dora_metrics}}
• Rationale: {{user_reasoning_or_default}}
• Rollback Implication: {{how_this_affects_rollback_capability}}

4. Generate Deployment Strategy Content

After facilitating all decision categories, prepare the content to append:

Content Structure:

## Deployment Strategy

### DORA Metrics Alignment

**Target Profile:**
- Deployment Frequency: {{target_frequency}}
- Lead Time for Changes: {{target_lead_time}}
- Change Failure Rate: {{target_failure_rate}}
- Mean Time to Recovery: {{target_mttr}}

### Deployment Pattern

**Pattern:** {{deployment_pattern}}
**Implementation:** {{how_pattern_is_implemented_with_chosen_tools}}
**Rationale:** {{rationale}}

### Feature Flag Strategy

**Approach:** {{feature_flag_approach}}
**Tool:** {{tool_or_na}} ({{version}})
**Integration:** {{how_flags_integrate_with_deployment_pattern}}

### Database Migration Strategy

**Approach:** {{migration_approach}}
**Coordination:** {{how_migrations_coordinate_with_deployments}}
**Rollback Impact:** {{how_this_affects_rollback}}

### Rollback Strategy

**Type:** {{automated_manual_hybrid}}
**Triggers:** {{rollback_criteria}}
**Mechanism:** {{rollback_mechanism}}
**Data Handling:** {{data_rollback_approach}}
**Testing:** {{rollback_testing_approach}}

### Zero-Downtime Approach

**Requirement Level:** {{required_maintenance_window_best_effort}}
**Implementation:**
{{graceful_shutdown_health_checks_connection_draining}}

### Multi-Region Strategy

**Approach:** {{single_active_passive_active_active}}
{{multi_region_details_if_applicable}}

### Deployment Strategy Summary

{{visual_summary_of_complete_deployment_flow_from_commit_to_production}}

5. Present Content and Menu

Show the generated deployment strategy content and present choices:

"I've documented our deployment strategy decisions. These decisions directly impact your DORA metrics - particularly deployment frequency ({{assessment}}) and mean time to recovery ({{assessment}}).

Here's what I'll add to the document:

[Show the complete markdown content from step 4]

What would you like to do? [A] Advanced Elicitation - Explore innovative approaches to deployment strategies [P] Party Mode - Review deployment strategy from multiple perspectives [C] Continue - Save these decisions and move to final validation"

6. Handle Menu Selection

If 'A' (Advanced Elicitation):

• Invoke the bmad-advanced-elicitation skill with deployment strategy context
• Process enhanced insights about deployment patterns
• Ask user: "Accept these enhancements to the deployment strategy? (y/n)"
• If yes: Update content, then return to A/P/C menu
• If no: Keep original content, then return to A/P/C menu

If 'P' (Party Mode):

• Invoke the bmad-party-mode skill with deployment strategy context
• Process collaborative insights about deployment trade-offs
• Ask user: "Accept these changes to the deployment strategy? (y/n)"
• If yes: Update content, then return to A/P/C menu
• If no: Keep original content, then return to A/P/C menu

If 'C' (Continue):

• Append the final content to {planning_artifacts}/pipeline.md
• Update frontmatter: stepsCompleted: [1, 2, 3, 4]
• Load ./step-05-validation.md

APPEND TO DOCUMENT:

When user selects 'C', append the content directly to the document using the structure from step 4.

SUCCESS METRICS:

✅ All deployment strategy decisions made collaboratively ✅ Technology versions verified using web search ✅ DORA metrics referenced for each decision trade-off ✅ Decision rationale clearly documented with DORA impact ✅ Rollback implications considered for every decision ✅ Pipeline stage decisions from step 3 leveraged correctly ✅ User provided appropriate level of explanation for skill level ✅ A/P/C menu presented and handled correctly ✅ Content properly appended to document when C selected

FAILURE MODES:

❌ Making recommendations instead of facilitating decisions ❌ Not verifying technology versions with web search ❌ Not referencing DORA metrics when discussing trade-offs ❌ Ignoring rollback implications of deployment decisions ❌ Not adapting explanations to user skill level ❌ Not considering pipeline stage decisions from step 3 ❌ Not presenting A/P/C menu after content generation

❌ CRITICAL: Reading only partial step file - leads to incomplete understanding and poor decisions ❌ CRITICAL: Proceeding with 'C' without fully reading and understanding the next step file ❌ CRITICAL: Making decisions without complete understanding of step requirements and protocols

NEXT STEP:

After user selects 'C' and content is saved to document, load ./step-05-validation.md to validate the complete pipeline architecture.

Remember: Do NOT proceed to step-05 until user explicitly selects 'C' from the A/P/C menu and content is saved!