ros/BMAD-METHOD
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

specify md ot yaml

Browse Source
This commit is contained in:
Brian Madison
2025-07-06 18:26:09 -05:00
parent 339745c3f3
commit 746ba573fa
58 changed files with 7606 additions and 7404 deletions
Download Patch File Download Diff File Expand all files Collapse all files

19
expansion-packs/bmad-infrastructure-devops/agents/infra-devops-platform.md
View File

@@ -3,6 +3,9 @@
CRITICAL: Read the full YAML, start activation to alter your state of being, follow startup section instructions, stay in this being until told to exit this mode:
```yaml
root: .bmad-infrastructure-devops
IDE-FILE-RESOLUTION: Dependencies map to files as {root}/{type}/{name} where root=".bmad-core", type=folder (tasks/templates/checklists/utils), name=dependency name.
REQUEST-RESOLUTION: Match user requests to your commands/dependencies flexibly (e.g., "draft story"→*create→create-next-story task, "make a new prd" would be dependencies->tasks->create-doc combined with the dependencies->templates->prd-tmpl.md), or ask for clarification if ambiguous.
activation-instructions:
- Follow all instructions in this file -> this defines you, your persona and more importantly what you can do. STAY IN CHARACTER!
- Only read the files/tasks listed here when user selects them for execution to minimize context usage
@@ -43,16 +46,14 @@ commands:
- '*exit" - Say goodbye as Alex, the DevOps Infrastructure Specialist, and then abandon inhabiting this persona'
dependencies:
tasks:
- create-doc
- review-infrastructure
- validate-infrastructure
- create-doc.md
- review-infrastructure.md
- validate-infrastructure.md
templates:
- infrastructure-architecture-tmpl
- infrastructure-platform-from-arch-tmpl
- infrastructure-architecture-tmpl.yaml
- infrastructure-platform-from-arch-tmpl.yaml
checklists:
- infrastructure-checklist
- infrastructure-checklist.md
data:
- technical-preferences
utils:
- template-format
- technical-preferences.md
```

415
expansion-packs/bmad-infrastructure-devops/templates/infrastructure-architecture-tmpl.md
View File

@@ -1,415 +0,0 @@
# {{Project Name}} Infrastructure Architecture
[[LLM: Initial Setup
1. Replace {{Project Name}} with the actual project name throughout the document
2. Gather and review required inputs:
- Product Requirements Document (PRD) - Required for business needs and scale requirements
- Main System Architecture - Required for infrastructure dependencies
- Technical Preferences/Tech Stack Document - Required for technology choices
- PRD Technical Assumptions - Required for cross-referencing repository and service architecture
If any required documents are missing, ask user: "I need the following documents to create a comprehensive infrastructure architecture: [list missing]. Would you like to proceed with available information or provide the missing documents first?"
3. <critical_rule>Cross-reference with PRD Technical Assumptions to ensure infrastructure decisions align with repository and service architecture decisions made in the system architecture.</critical_rule>
Output file location: `docs/infrastructure-architecture.md`]]
## Infrastructure Overview
[[LLM: Review the product requirements document to understand business needs and scale requirements. Analyze the main system architecture to identify infrastructure dependencies. Document non-functional requirements (performance, scalability, reliability, security). Cross-reference with PRD Technical Assumptions to ensure alignment with repository and service architecture decisions.]]
- Cloud Provider(s)
- Core Services & Resources
- Regional Architecture
- Multi-environment Strategy
@{example: cloud_strategy}
- **Cloud Provider:** AWS (primary), with multi-cloud capability for critical services
- **Core Services:** EKS for container orchestration, RDS for databases, S3 for storage, CloudFront for CDN
- **Regional Architecture:** Multi-region active-passive with primary in us-east-1, DR in us-west-2
- **Multi-environment Strategy:** Development, Staging, UAT, Production with identical infrastructure patterns
@{/example}
[[LLM: Infrastructure Elicitation Options
Present user with domain-specific elicitation options:
"For the Infrastructure Overview section, I can explore:
1. **Multi-Cloud Strategy Analysis** - Evaluate cloud provider options and vendor lock-in considerations
2. **Regional Distribution Planning** - Analyze latency requirements and data residency needs
3. **Environment Isolation Strategy** - Design security boundaries and resource segregation
4. **Scalability Patterns Review** - Assess auto-scaling needs and traffic patterns
5. **Compliance Requirements Analysis** - Review regulatory and security compliance needs
6. **Cost-Benefit Analysis** - Compare infrastructure options and TCO
7. **Proceed to next section**
Select an option (1-7):"]]
## Infrastructure as Code (IaC)
[[LLM: Define IaC approach based on technical preferences and existing patterns. Consider team expertise, tooling ecosystem, and maintenance requirements.]]
- Tools & Frameworks
- Repository Structure
- State Management
- Dependency Management
<critical_rule>All infrastructure must be defined as code. No manual resource creation in production environments.</critical_rule>
## Environment Configuration
[[LLM: Design environment strategy that supports the development workflow while maintaining security and cost efficiency. Reference the Environment Transition Strategy section for promotion details.]]
- Environment Promotion Strategy
- Configuration Management
- Secret Management
- Feature Flag Integration
<<REPEAT: environment>>
### {{environment_name}} Environment
- **Purpose:** {{environment_purpose}}
- **Resources:** {{environment_resources}}
- **Access Control:** {{environment_access}}
- **Data Classification:** {{environment_data_class}}
<</REPEAT>>
## Environment Transition Strategy
[[LLM: Detail the complete lifecycle of code and configuration changes from development to production. Include governance, testing gates, and rollback procedures.]]
- Development to Production Pipeline
- Deployment Stages and Gates
- Approval Workflows and Authorities
- Rollback Procedures
- Change Cadence and Release Windows
- Environment-Specific Configuration Management
## Network Architecture
[[LLM: Design network topology considering security zones, traffic patterns, and compliance requirements. Reference main architecture for service communication patterns.
Create Mermaid diagram showing:
- VPC/Network structure
- Security zones and boundaries
- Traffic flow patterns
- Load balancer placement
- Service mesh topology (if applicable)]]
- VPC/VNET Design
- Subnet Strategy
- Security Groups & NACLs
- Load Balancers & API Gateways
- Service Mesh (if applicable)
```mermaid
graph TB
subgraph "Production VPC"
subgraph "Public Subnets"
ALB[Application Load Balancer]
end
subgraph "Private Subnets"
EKS[EKS Cluster]
RDS[(RDS Database)]
end
end
Internet((Internet)) --> ALB
ALB --> EKS
EKS --> RDS
```
^^CONDITION: uses_service_mesh^^
### Service Mesh Architecture
- **Mesh Technology:** {{service_mesh_tech}}
- **Traffic Management:** {{traffic_policies}}
- **Security Policies:** {{mesh_security}}
- **Observability Integration:** {{mesh_observability}}
^^/CONDITION: uses_service_mesh^^
## Compute Resources
[[LLM: Select compute strategy based on application architecture (microservices, serverless, monolithic). Consider cost, scalability, and operational complexity.]]
- Container Strategy
- Serverless Architecture
- VM/Instance Configuration
- Auto-scaling Approach
^^CONDITION: uses_kubernetes^^
### Kubernetes Architecture
- **Cluster Configuration:** {{k8s_cluster_config}}
- **Node Groups:** {{k8s_node_groups}}
- **Networking:** {{k8s_networking}}
- **Storage Classes:** {{k8s_storage}}
- **Security Policies:** {{k8s_security}}
^^/CONDITION: uses_kubernetes^^
## Data Resources
[[LLM: Design data infrastructure based on data architecture from main system design. Consider data volumes, access patterns, compliance, and recovery requirements.
Create data flow diagram showing:
- Database topology
- Replication patterns
- Backup flows
- Data migration paths]]
- Database Deployment Strategy
- Backup & Recovery
- Replication & Failover
- Data Migration Strategy
## Security Architecture
[[LLM: Implement defense-in-depth strategy. Reference security requirements from PRD and compliance needs. Consider zero-trust principles where applicable.]]
- IAM & Authentication
- Network Security
- Data Encryption
- Compliance Controls
- Security Scanning & Monitoring
<critical_rule>Apply principle of least privilege for all access controls. Document all security exceptions with business justification.</critical_rule>
## Shared Responsibility Model
[[LLM: Clearly define boundaries between cloud provider, platform team, development team, and security team responsibilities. This is critical for operational success.]]
- Cloud Provider Responsibilities
- Platform Team Responsibilities
- Development Team Responsibilities
- Security Team Responsibilities
- Operational Monitoring Ownership
- Incident Response Accountability Matrix
@{example: responsibility_matrix}
| Component | Cloud Provider | Platform Team | Dev Team | Security Team |
| -------------------- | -------------- | ------------- | -------------- | ------------- |
| Physical Security | ✓ | - | - | Audit |
| Network Security | Partial | ✓ | Config | Audit |
| Application Security | - | Tools | ✓ | Review |
| Data Encryption | Engine | Config | Implementation | Standards |
@{/example}
## Monitoring & Observability
[[LLM: Design comprehensive observability strategy covering metrics, logs, traces, and business KPIs. Ensure alignment with SLA/SLO requirements.]]
- Metrics Collection
- Logging Strategy
- Tracing Implementation
- Alerting & Incident Response
- Dashboards & Visualization
## CI/CD Pipeline
[[LLM: Design deployment pipeline that balances speed with safety. Include progressive deployment strategies and automated quality gates.
Create pipeline diagram showing:
- Build stages
- Test gates
- Deployment stages
- Approval points
- Rollback triggers]]
- Pipeline Architecture
- Build Process
- Deployment Strategy
- Rollback Procedures
- Approval Gates
^^CONDITION: uses_progressive_deployment^^
### Progressive Deployment Strategy
- **Canary Deployment:** {{canary_config}}
- **Blue-Green Deployment:** {{blue_green_config}}
- **Feature Flags:** {{feature_flag_integration}}
- **Traffic Splitting:** {{traffic_split_rules}}
^^/CONDITION: uses_progressive_deployment^^
## Disaster Recovery
[[LLM: Design DR strategy based on business continuity requirements. Define clear RTO/RPO targets and ensure they align with business needs.]]
- Backup Strategy
- Recovery Procedures
- RTO & RPO Targets
- DR Testing Approach
<critical_rule>DR procedures must be tested at least quarterly. Document test results and improvement actions.</critical_rule>
## Cost Optimization
[[LLM: Balance cost efficiency with performance and reliability requirements. Include both immediate optimizations and long-term strategies.]]
- Resource Sizing Strategy
- Reserved Instances/Commitments
- Cost Monitoring & Reporting
- Optimization Recommendations
## BMad Integration Architecture
[[LLM: Design infrastructure to specifically support other BMad agents and their workflows. This ensures the infrastructure enables the entire BMad methodology.]]
### Development Agent Support
- Container platform for development environments
- GitOps workflows for application deployment
- Service mesh integration for development testing
- Developer self-service platform capabilities
### Product & Architecture Alignment
- Infrastructure implementing PRD scalability requirements
- Deployment automation supporting product iteration speed
- Service reliability meeting product SLAs
- Architecture patterns properly implemented in infrastructure
### Cross-Agent Integration Points
- CI/CD pipelines supporting Frontend, Backend, and Full Stack development workflows
- Monitoring and observability data accessible to QA and DevOps agents
- Infrastructure enabling Design Architect's UI/UX performance requirements
- Platform supporting Analyst's data collection and analysis needs
## DevOps/Platform Feasibility Review
[[LLM: CRITICAL STEP - Present architectural blueprint summary to DevOps/Platform Engineering Agent for feasibility review. Request specific feedback on:
- **Operational Complexity:** Are the proposed patterns implementable with current tooling and expertise?
- **Resource Constraints:** Do infrastructure requirements align with available resources and budgets?
- **Security Implementation:** Are security patterns achievable with current security toolchain?
- **Operational Overhead:** Will the proposed architecture create excessive operational burden?
- **Technology Constraints:** Are selected technologies compatible with existing infrastructure?
Document all feasibility feedback and concerns raised. Iterate on architectural decisions based on operational constraints and feedback.
<critical_rule>Address all critical feasibility concerns before proceeding to final architecture documentation. If critical blockers identified, revise architecture before continuing.</critical_rule>]]
### Feasibility Assessment Results
- **Green Light Items:** {{feasible_items}}
- **Yellow Light Items:** {{items_needing_adjustment}}
- **Red Light Items:** {{items_requiring_redesign}}
- **Mitigation Strategies:** {{mitigation_plans}}
## Infrastructure Verification
### Validation Framework
This infrastructure architecture will be validated using the comprehensive `infrastructure-checklist.md`, with particular focus on Section 12: Architecture Documentation Validation. The checklist ensures:
- Completeness of architecture documentation
- Consistency with broader system architecture
- Appropriate level of detail for different stakeholders
- Clear implementation guidance
- Future evolution considerations
### Validation Process
The architecture documentation validation should be performed:
- After initial architecture development
- After significant architecture changes
- Before major implementation phases
- During periodic architecture reviews
The Platform Engineer should use the infrastructure checklist to systematically validate all aspects of this architecture document.
## Implementation Handoff
[[LLM: Create structured handoff documentation for implementation team. This ensures architecture decisions are properly communicated and implemented.]]
### Architecture Decision Records (ADRs)
Create ADRs for key infrastructure decisions:
- Cloud provider selection rationale
- Container orchestration platform choice
- Networking architecture decisions
- Security implementation choices
- Cost optimization trade-offs
### Implementation Validation Criteria
Define specific criteria for validating correct implementation:
- Infrastructure as Code quality gates
- Security compliance checkpoints
- Performance benchmarks
- Cost targets
- Operational readiness criteria
### Knowledge Transfer Requirements
- Technical documentation for operations team
- Runbook creation requirements
- Training needs for platform team
- Handoff meeting agenda items
## Infrastructure Evolution
[[LLM: Document the long-term vision and evolution path for the infrastructure. Consider technology trends, anticipated growth, and technical debt management.]]
- Technical Debt Inventory
- Planned Upgrades and Migrations
- Deprecation Schedule
- Technology Roadmap
- Capacity Planning
- Scalability Considerations
## Integration with Application Architecture
[[LLM: Map infrastructure components to application services. Ensure infrastructure design supports application requirements and patterns defined in main architecture.]]
- Service-to-Infrastructure Mapping
- Application Dependency Matrix
- Performance Requirements Implementation
- Security Requirements Implementation
- Data Flow to Infrastructure Correlation
- API Gateway and Service Mesh Integration
## Cross-Team Collaboration
[[LLM: Define clear interfaces and communication patterns between teams. This section is critical for operational success and should include specific touchpoints and escalation paths.]]
- Platform Engineer and Developer Touchpoints
- Frontend/Backend Integration Requirements
- Product Requirements to Infrastructure Mapping
- Architecture Decision Impact Analysis
- Design Architect UI/UX Infrastructure Requirements
- Analyst Research Integration
## Infrastructure Change Management
[[LLM: Define structured process for infrastructure changes. Include risk assessment, testing requirements, and rollback procedures.]]
- Change Request Process
- Risk Assessment
- Testing Strategy
- Validation Procedures
[[LLM: Final Review - Ensure all sections are complete and consistent. Verify feasibility review was conducted and all concerns addressed. Apply final validation against infrastructure checklist.]]
---
_Document Version: 1.0_
_Last Updated: {{current_date}}_
_Next Review: {{review_date}}_

424
expansion-packs/bmad-infrastructure-devops/templates/infrastructure-architecture-tmpl.yaml Normal file
View File

@@ -0,0 +1,424 @@
template:
id: infrastructure-architecture-template-v2
name: Infrastructure Architecture
version: 2.0
output:
format: markdown
filename: docs/infrastructure-architecture.md
title: "{{project_name}} Infrastructure Architecture"
workflow:
mode: interactive
elicitation: advanced-elicitation
custom_elicitation:
title: "Infrastructure Architecture Elicitation Actions"
sections:
- id: infrastructure-overview
options:
- "Multi-Cloud Strategy Analysis - Evaluate cloud provider options and vendor lock-in considerations"
- "Regional Distribution Planning - Analyze latency requirements and data residency needs"
- "Environment Isolation Strategy - Design security boundaries and resource segregation"
- "Scalability Patterns Review - Assess auto-scaling needs and traffic patterns"
- "Compliance Requirements Analysis - Review regulatory and security compliance needs"
- "Cost-Benefit Analysis - Compare infrastructure options and TCO"
- "Proceed to next section"
sections:
- id: initial-setup
instruction: |
Initial Setup
1. Replace {{project_name}} with the actual project name throughout the document
2. Gather and review required inputs:
- Product Requirements Document (PRD) - Required for business needs and scale requirements
- Main System Architecture - Required for infrastructure dependencies
- Technical Preferences/Tech Stack Document - Required for technology choices
- PRD Technical Assumptions - Required for cross-referencing repository and service architecture
If any required documents are missing, ask user: "I need the following documents to create a comprehensive infrastructure architecture: [list missing]. Would you like to proceed with available information or provide the missing documents first?"
3. <critical_rule>Cross-reference with PRD Technical Assumptions to ensure infrastructure decisions align with repository and service architecture decisions made in the system architecture.</critical_rule>
Output file location: `docs/infrastructure-architecture.md`
- id: infrastructure-overview
title: Infrastructure Overview
instruction: |
Review the product requirements document to understand business needs and scale requirements. Analyze the main system architecture to identify infrastructure dependencies. Document non-functional requirements (performance, scalability, reliability, security). Cross-reference with PRD Technical Assumptions to ensure alignment with repository and service architecture decisions.
elicit: true
custom_elicitation: infrastructure-overview
template: |
- Cloud Provider(s)
- Core Services & Resources
- Regional Architecture
- Multi-environment Strategy
examples:
- |
- **Cloud Provider:** AWS (primary), with multi-cloud capability for critical services
- **Core Services:** EKS for container orchestration, RDS for databases, S3 for storage, CloudFront for CDN
- **Regional Architecture:** Multi-region active-passive with primary in us-east-1, DR in us-west-2
- **Multi-environment Strategy:** Development, Staging, UAT, Production with identical infrastructure patterns
- id: iac
title: Infrastructure as Code (IaC)
instruction: Define IaC approach based on technical preferences and existing patterns. Consider team expertise, tooling ecosystem, and maintenance requirements.
template: |
- Tools & Frameworks
- Repository Structure
- State Management
- Dependency Management
<critical_rule>All infrastructure must be defined as code. No manual resource creation in production environments.</critical_rule>
- id: environment-configuration
title: Environment Configuration
instruction: Design environment strategy that supports the development workflow while maintaining security and cost efficiency. Reference the Environment Transition Strategy section for promotion details.
template: |
- Environment Promotion Strategy
- Configuration Management
- Secret Management
- Feature Flag Integration
sections:
- id: environments
repeatable: true
title: "{{environment_name}} Environment"
template: |
- **Purpose:** {{environment_purpose}}
- **Resources:** {{environment_resources}}
- **Access Control:** {{environment_access}}
- **Data Classification:** {{environment_data_class}}
- id: environment-transition
title: Environment Transition Strategy
instruction: Detail the complete lifecycle of code and configuration changes from development to production. Include governance, testing gates, and rollback procedures.
template: |
- Development to Production Pipeline
- Deployment Stages and Gates
- Approval Workflows and Authorities
- Rollback Procedures
- Change Cadence and Release Windows
- Environment-Specific Configuration Management
- id: network-architecture
title: Network Architecture
instruction: |
Design network topology considering security zones, traffic patterns, and compliance requirements. Reference main architecture for service communication patterns.
Create Mermaid diagram showing:
- VPC/Network structure
- Security zones and boundaries
- Traffic flow patterns
- Load balancer placement
- Service mesh topology (if applicable)
template: |
- VPC/VNET Design
- Subnet Strategy
- Security Groups & NACLs
- Load Balancers & API Gateways
- Service Mesh (if applicable)
sections:
- id: network-diagram
type: mermaid
mermaid_type: graph
template: |
graph TB
subgraph "Production VPC"
subgraph "Public Subnets"
ALB[Application Load Balancer]
end
subgraph "Private Subnets"
EKS[EKS Cluster]
RDS[(RDS Database)]
end
end
Internet((Internet)) --> ALB
ALB --> EKS
EKS --> RDS
- id: service-mesh
title: Service Mesh Architecture
condition: Uses service mesh
template: |
- **Mesh Technology:** {{service_mesh_tech}}
- **Traffic Management:** {{traffic_policies}}
- **Security Policies:** {{mesh_security}}
- **Observability Integration:** {{mesh_observability}}
- id: compute-resources
title: Compute Resources
instruction: Select compute strategy based on application architecture (microservices, serverless, monolithic). Consider cost, scalability, and operational complexity.
template: |
- Container Strategy
- Serverless Architecture
- VM/Instance Configuration
- Auto-scaling Approach
sections:
- id: kubernetes
title: Kubernetes Architecture
condition: Uses Kubernetes
template: |
- **Cluster Configuration:** {{k8s_cluster_config}}
- **Node Groups:** {{k8s_node_groups}}
- **Networking:** {{k8s_networking}}
- **Storage Classes:** {{k8s_storage}}
- **Security Policies:** {{k8s_security}}
- id: data-resources
title: Data Resources
instruction: |
Design data infrastructure based on data architecture from main system design. Consider data volumes, access patterns, compliance, and recovery requirements.
Create data flow diagram showing:
- Database topology
- Replication patterns
- Backup flows
- Data migration paths
template: |
- Database Deployment Strategy
- Backup & Recovery
- Replication & Failover
- Data Migration Strategy
- id: security-architecture
title: Security Architecture
instruction: Implement defense-in-depth strategy. Reference security requirements from PRD and compliance needs. Consider zero-trust principles where applicable.
template: |
- IAM & Authentication
- Network Security
- Data Encryption
- Compliance Controls
- Security Scanning & Monitoring
<critical_rule>Apply principle of least privilege for all access controls. Document all security exceptions with business justification.</critical_rule>
- id: shared-responsibility
title: Shared Responsibility Model
instruction: Clearly define boundaries between cloud provider, platform team, development team, and security team responsibilities. This is critical for operational success.
template: |
- Cloud Provider Responsibilities
- Platform Team Responsibilities
- Development Team Responsibilities
- Security Team Responsibilities
- Operational Monitoring Ownership
- Incident Response Accountability Matrix
examples:
- |
| Component | Cloud Provider | Platform Team | Dev Team | Security Team |
| -------------------- | -------------- | ------------- | -------------- | ------------- |
| Physical Security | ✓ | - | - | Audit |
| Network Security | Partial | ✓ | Config | Audit |
| Application Security | - | Tools | ✓ | Review |
| Data Encryption | Engine | Config | Implementation | Standards |
- id: monitoring-observability
title: Monitoring & Observability
instruction: Design comprehensive observability strategy covering metrics, logs, traces, and business KPIs. Ensure alignment with SLA/SLO requirements.
template: |
- Metrics Collection
- Logging Strategy
- Tracing Implementation
- Alerting & Incident Response
- Dashboards & Visualization
- id: cicd-pipeline
title: CI/CD Pipeline
instruction: |
Design deployment pipeline that balances speed with safety. Include progressive deployment strategies and automated quality gates.
Create pipeline diagram showing:
- Build stages
- Test gates
- Deployment stages
- Approval points
- Rollback triggers
template: |
- Pipeline Architecture
- Build Process
- Deployment Strategy
- Rollback Procedures
- Approval Gates
sections:
- id: progressive-deployment
title: Progressive Deployment Strategy
condition: Uses progressive deployment
template: |
- **Canary Deployment:** {{canary_config}}
- **Blue-Green Deployment:** {{blue_green_config}}
- **Feature Flags:** {{feature_flag_integration}}
- **Traffic Splitting:** {{traffic_split_rules}}
- id: disaster-recovery
title: Disaster Recovery
instruction: Design DR strategy based on business continuity requirements. Define clear RTO/RPO targets and ensure they align with business needs.
template: |
- Backup Strategy
- Recovery Procedures
- RTO & RPO Targets
- DR Testing Approach
<critical_rule>DR procedures must be tested at least quarterly. Document test results and improvement actions.</critical_rule>
- id: cost-optimization
title: Cost Optimization
instruction: Balance cost efficiency with performance and reliability requirements. Include both immediate optimizations and long-term strategies.
template: |
- Resource Sizing Strategy
- Reserved Instances/Commitments
- Cost Monitoring & Reporting
- Optimization Recommendations
- id: bmad-integration
title: BMad Integration Architecture
instruction: Design infrastructure to specifically support other BMad agents and their workflows. This ensures the infrastructure enables the entire BMad methodology.
sections:
- id: dev-agent-support
title: Development Agent Support
template: |
- Container platform for development environments
- GitOps workflows for application deployment
- Service mesh integration for development testing
- Developer self-service platform capabilities
- id: product-architecture-alignment
title: Product & Architecture Alignment
template: |
- Infrastructure implementing PRD scalability requirements
- Deployment automation supporting product iteration speed
- Service reliability meeting product SLAs
- Architecture patterns properly implemented in infrastructure
- id: cross-agent-integration
title: Cross-Agent Integration Points
template: |
- CI/CD pipelines supporting Frontend, Backend, and Full Stack development workflows
- Monitoring and observability data accessible to QA and DevOps agents
- Infrastructure enabling Design Architect's UI/UX performance requirements
- Platform supporting Analyst's data collection and analysis needs
- id: feasibility-review
title: DevOps/Platform Feasibility Review
instruction: |
CRITICAL STEP - Present architectural blueprint summary to DevOps/Platform Engineering Agent for feasibility review. Request specific feedback on:
- **Operational Complexity:** Are the proposed patterns implementable with current tooling and expertise?
- **Resource Constraints:** Do infrastructure requirements align with available resources and budgets?
- **Security Implementation:** Are security patterns achievable with current security toolchain?
- **Operational Overhead:** Will the proposed architecture create excessive operational burden?
- **Technology Constraints:** Are selected technologies compatible with existing infrastructure?
Document all feasibility feedback and concerns raised. Iterate on architectural decisions based on operational constraints and feedback.
<critical_rule>Address all critical feasibility concerns before proceeding to final architecture documentation. If critical blockers identified, revise architecture before continuing.</critical_rule>
sections:
- id: feasibility-results
title: Feasibility Assessment Results
template: |
- **Green Light Items:** {{feasible_items}}
- **Yellow Light Items:** {{items_needing_adjustment}}
- **Red Light Items:** {{items_requiring_redesign}}
- **Mitigation Strategies:** {{mitigation_plans}}
- id: infrastructure-verification
title: Infrastructure Verification
sections:
- id: validation-framework
title: Validation Framework
content: |
This infrastructure architecture will be validated using the comprehensive `infrastructure-checklist.md`, with particular focus on Section 12: Architecture Documentation Validation. The checklist ensures:
- Completeness of architecture documentation
- Consistency with broader system architecture
- Appropriate level of detail for different stakeholders
- Clear implementation guidance
- Future evolution considerations
- id: validation-process
title: Validation Process
content: |
The architecture documentation validation should be performed:
- After initial architecture development
- After significant architecture changes
- Before major implementation phases
- During periodic architecture reviews
The Platform Engineer should use the infrastructure checklist to systematically validate all aspects of this architecture document.
- id: implementation-handoff
title: Implementation Handoff
instruction: Create structured handoff documentation for implementation team. This ensures architecture decisions are properly communicated and implemented.
sections:
- id: adrs
title: Architecture Decision Records (ADRs)
content: |
Create ADRs for key infrastructure decisions:
- Cloud provider selection rationale
- Container orchestration platform choice
- Networking architecture decisions
- Security implementation choices
- Cost optimization trade-offs
- id: implementation-validation
title: Implementation Validation Criteria
content: |
Define specific criteria for validating correct implementation:
- Infrastructure as Code quality gates
- Security compliance checkpoints
- Performance benchmarks
- Cost targets
- Operational readiness criteria
- id: knowledge-transfer
title: Knowledge Transfer Requirements
template: |
- Technical documentation for operations team
- Runbook creation requirements
- Training needs for platform team
- Handoff meeting agenda items
- id: infrastructure-evolution
title: Infrastructure Evolution
instruction: Document the long-term vision and evolution path for the infrastructure. Consider technology trends, anticipated growth, and technical debt management.
template: |
- Technical Debt Inventory
- Planned Upgrades and Migrations
- Deprecation Schedule
- Technology Roadmap
- Capacity Planning
- Scalability Considerations
- id: app-integration
title: Integration with Application Architecture
instruction: Map infrastructure components to application services. Ensure infrastructure design supports application requirements and patterns defined in main architecture.
template: |
- Service-to-Infrastructure Mapping
- Application Dependency Matrix
- Performance Requirements Implementation
- Security Requirements Implementation
- Data Flow to Infrastructure Correlation
- API Gateway and Service Mesh Integration
- id: cross-team-collaboration
title: Cross-Team Collaboration
instruction: Define clear interfaces and communication patterns between teams. This section is critical for operational success and should include specific touchpoints and escalation paths.
template: |
- Platform Engineer and Developer Touchpoints
- Frontend/Backend Integration Requirements
- Product Requirements to Infrastructure Mapping
- Architecture Decision Impact Analysis
- Design Architect UI/UX Infrastructure Requirements
- Analyst Research Integration
- id: change-management
title: Infrastructure Change Management
instruction: Define structured process for infrastructure changes. Include risk assessment, testing requirements, and rollback procedures.
template: |
- Change Request Process
- Risk Assessment
- Testing Strategy
- Validation Procedures
- id: final-review
instruction: Final Review - Ensure all sections are complete and consistent. Verify feasibility review was conducted and all concerns addressed. Apply final validation against infrastructure checklist.
content: |
---
_Document Version: 1.0_
_Last Updated: {{current_date}}_
_Next Review: {{review_date}}_

BIN
expansion-packs/bmad-infrastructure-devops/templates/infrastructure-platform-from-arch-tmpl.md
View File

Binary file not shown.

629
expansion-packs/bmad-infrastructure-devops/templates/infrastructure-platform-from-arch-tmpl.yaml Normal file
View File

@@ -0,0 +1,629 @@
template:
id: infrastructure-platform-template-v2
name: Platform Infrastructure Implementation
version: 2.0
output:
format: markdown
filename: docs/platform-infrastructure/platform-implementation.md
title: "{{project_name}} Platform Infrastructure Implementation"
workflow:
mode: interactive
elicitation: advanced-elicitation
custom_elicitation:
title: "Platform Implementation Elicitation Actions"
sections:
- id: foundation-infrastructure
options:
- "Platform Layer Security Hardening - Additional security controls and compliance validation"
- "Performance Optimization - Network and resource optimization"
- "Operational Excellence Enhancement - Automation and monitoring improvements"
- "Platform Integration Validation - Verify foundation supports upper layers"
- "Developer Experience Analysis - Foundation impact on developer workflows"
- "Disaster Recovery Testing - Foundation resilience validation"
- "BMAD Workflow Integration - Cross-agent support verification"
- "Finalize and Proceed to Container Platform"
sections:
- id: initial-setup
instruction: |
Initial Setup
1. Replace {{project_name}} with the actual project name throughout the document
2. Gather and review required inputs:
- **Infrastructure Architecture Document** (Primary input - REQUIRED)
- Infrastructure Change Request (if applicable)
- Infrastructure Guidelines
- Technology Stack Document
- Infrastructure Checklist
- NOTE: If Infrastructure Architecture Document is missing, HALT and request: "I need the Infrastructure Architecture Document to proceed with platform implementation. This document defines the infrastructure design that we'll be implementing."
3. Validate that the infrastructure architecture has been reviewed and approved
4. <critical_rule>All platform implementation must align with the approved infrastructure architecture. Any deviations require architect approval.</critical_rule>
Output file location: `docs/platform-infrastructure/platform-implementation.md`
- id: executive-summary
title: Executive Summary
instruction: Provide a high-level overview of the platform infrastructure being implemented, referencing the infrastructure architecture document's key decisions and requirements.
template: |
- Platform implementation scope and objectives
- Key architectural decisions being implemented
- Expected outcomes and benefits
- Timeline and milestones
- id: joint-planning
title: Joint Planning Session with Architect
instruction: Document the collaborative planning session between DevOps/Platform Engineer and Architect. This ensures alignment before implementation begins.
sections:
- id: architecture-alignment
title: Architecture Alignment Review
template: |
- Review of infrastructure architecture document
- Confirmation of design decisions
- Identification of any ambiguities or gaps
- Agreement on implementation approach
- id: implementation-strategy
title: Implementation Strategy Collaboration
template: |
- Platform layer sequencing
- Technology stack validation
- Integration approach between layers
- Testing and validation strategy
- id: risk-constraint
title: Risk & Constraint Discussion
template: |
- Technical risks and mitigation strategies
- Resource constraints and workarounds
- Timeline considerations
- Compliance and security requirements
- id: validation-planning
title: Implementation Validation Planning
template: |
- Success criteria for each platform layer
- Testing approach and acceptance criteria
- Rollback strategies
- Communication plan
- id: documentation-planning
title: Documentation & Knowledge Transfer Planning
template: |
- Documentation requirements
- Knowledge transfer approach
- Training needs identification
- Handoff procedures
- id: foundation-infrastructure
title: Foundation Infrastructure Layer
instruction: Implement the base infrastructure layer based on the infrastructure architecture. This forms the foundation for all platform services.
elicit: true
custom_elicitation: foundation-infrastructure
sections:
- id: cloud-provider-setup
title: Cloud Provider Setup
template: |
- Account/Subscription configuration
- Region selection and setup
- Resource group/organizational structure
- Cost management setup
- id: network-foundation
title: Network Foundation
type: code
language: hcl
template: |
# Example Terraform for VPC setup
module "vpc" {
source = "./modules/vpc"
cidr_block = "{{vpc_cidr}}"
availability_zones = {{availability_zones}}
public_subnets = {{public_subnets}}
private_subnets = {{private_subnets}}
}
- id: security-foundation
title: Security Foundation
template: |
- IAM roles and policies
- Security groups and NACLs
- Encryption keys (KMS/Key Vault)
- Compliance controls
- id: core-services
title: Core Services
template: |
- DNS configuration
- Certificate management
- Logging infrastructure
- Monitoring foundation
- id: container-platform
title: Container Platform Implementation
instruction: Build the container orchestration platform on top of the foundation infrastructure, following the architecture's container strategy.
sections:
- id: kubernetes-setup
title: Kubernetes Cluster Setup
sections:
- id: eks-setup
condition: Uses EKS
type: code
language: bash
template: |
# EKS Cluster Configuration
eksctl create cluster \
--name {{cluster_name}} \
--region {{aws_region}} \
--nodegroup-name {{nodegroup_name}} \
--node-type {{instance_type}} \
--nodes {{node_count}}
- id: aks-setup
condition: Uses AKS
type: code
language: bash
template: |
# AKS Cluster Configuration
az aks create \
--resource-group {{resource_group}} \
--name {{cluster_name}} \
--node-count {{node_count}} \
--node-vm-size {{vm_size}} \
--network-plugin azure
- id: node-configuration
title: Node Configuration
template: |
- Node groups/pools setup
- Autoscaling configuration
- Node security hardening
- Resource quotas and limits
- id: cluster-services
title: Cluster Services
template: |
- CoreDNS configuration
- Ingress controller setup
- Certificate management
- Storage classes
- id: security-rbac
title: Security & RBAC
template: |
- RBAC policies
- Pod security policies/standards
- Network policies
- Secrets management
- id: gitops-workflow
title: GitOps Workflow Implementation
instruction: Implement GitOps patterns for declarative infrastructure and application management as defined in the architecture.
sections:
- id: gitops-tooling
title: GitOps Tooling Setup
sections:
- id: argocd-setup
condition: Uses ArgoCD
type: code
language: yaml
template: |
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: argocd
namespace: argocd
spec:
source:
repoURL: {{repo_url}}
targetRevision: {{target_revision}}
path: {{path}}
- id: flux-setup
condition: Uses Flux
type: code
language: yaml
template: |
apiVersion: source.toolkit.fluxcd.io/v1beta2
kind: GitRepository
metadata:
name: flux-system
namespace: flux-system
spec:
interval: 1m
ref:
branch: {{branch}}
url: {{git_url}}
- id: repository-structure
title: Repository Structure
type: code
language: text
template: |
platform-gitops/
clusters/
production/
staging/
development/
infrastructure/
base/
overlays/
applications/
base/
overlays/
- id: deployment-workflows
title: Deployment Workflows
template: |
- Application deployment patterns
- Progressive delivery setup
- Rollback procedures
- Multi-environment promotion
- id: access-control
title: Access Control
template: |
- Git repository permissions
- GitOps tool RBAC
- Secret management integration
- Audit logging
- id: service-mesh
title: Service Mesh Implementation
instruction: Deploy service mesh for advanced traffic management, security, and observability as specified in the architecture.
sections:
- id: istio-mesh
title: Istio Service Mesh
condition: Uses Istio
sections:
- id: istio-install
type: code
language: bash
template: |
# Istio Installation
istioctl install --set profile={{istio_profile}} \
--set values.gateways.istio-ingressgateway.type={{ingress_type}}
- id: istio-config
template: |
- Control plane configuration
- Data plane injection
- Gateway configuration
- Observability integration
- id: linkerd-mesh
title: Linkerd Service Mesh
condition: Uses Linkerd
sections:
- id: linkerd-install
type: code
language: bash
template: |
# Linkerd Installation
linkerd install --cluster-name={{cluster_name}} | kubectl apply -f -
linkerd viz install | kubectl apply -f -
- id: linkerd-config
template: |
- Control plane setup
- Proxy injection
- Traffic policies
- Metrics collection
- id: traffic-management
title: Traffic Management
template: |
- Load balancing policies
- Circuit breakers
- Retry policies
- Canary deployments
- id: security-policies
title: Security Policies
template: |
- mTLS configuration
- Authorization policies
- Rate limiting
- Network segmentation
- id: developer-experience
title: Developer Experience Platform
instruction: Build the developer self-service platform to enable efficient development workflows as outlined in the architecture.
sections:
- id: developer-portal
title: Developer Portal
template: |
- Service catalog setup
- API documentation
- Self-service workflows
- Resource provisioning
- id: cicd-integration
title: CI/CD Integration
type: code
language: yaml
template: |
apiVersion: tekton.dev/v1beta1
kind: Pipeline
metadata:
name: platform-pipeline
spec:
tasks:
- name: build
taskRef:
name: build-task
- name: test
taskRef:
name: test-task
- name: deploy
taskRef:
name: gitops-deploy
- id: development-tools
title: Development Tools
template: |
- Local development setup
- Remote development environments
- Testing frameworks
- Debugging tools
- id: self-service
title: Self-Service Capabilities
template: |
- Environment provisioning
- Database creation
- Feature flag management
- Configuration management
- id: platform-integration
title: Platform Integration & Security Hardening
instruction: Implement comprehensive platform-wide integration and security controls across all layers.
sections:
- id: end-to-end-security
title: End-to-End Security
template: |
- Platform-wide security policies
- Cross-layer authentication
- Encryption in transit and at rest
- Compliance validation
- id: integrated-monitoring
title: Integrated Monitoring
type: code
language: yaml
template: |
apiVersion: v1
kind: ConfigMap
metadata:
name: prometheus-config
data:
prometheus.yaml: |
global:
scrape_interval: {{scrape_interval}}
scrape_configs:
- job_name: 'kubernetes-pods'
kubernetes_sd_configs:
- role: pod
- id: platform-observability
title: Platform Observability
template: |
- Metrics aggregation
- Log collection and analysis
- Distributed tracing
- Dashboard creation
- id: backup-dr
title: Backup & Disaster Recovery
template: |
- Platform backup strategy
- Disaster recovery procedures
- RTO/RPO validation
- Recovery testing
- id: platform-operations
title: Platform Operations & Automation
instruction: Establish operational procedures and automation for platform management.
sections:
- id: monitoring-alerting
title: Monitoring & Alerting
template: |
- SLA/SLO monitoring
- Alert routing
- Incident response
- Performance baselines
- id: automation-framework
title: Automation Framework
type: code
language: yaml
template: |
apiVersion: operators.coreos.com/v1alpha1
kind: ClusterServiceVersion
metadata:
name: platform-operator
spec:
customresourcedefinitions:
owned:
- name: platformconfigs.platform.io
version: v1alpha1
- id: maintenance-procedures
title: Maintenance Procedures
template: |
- Upgrade procedures
- Patch management
- Certificate rotation
- Capacity management
- id: operational-runbooks
title: Operational Runbooks
template: |
- Common operational tasks
- Troubleshooting guides
- Emergency procedures
- Recovery playbooks
- id: bmad-workflow-integration
title: BMAD Workflow Integration
instruction: Validate that the platform supports all BMAD agent workflows and cross-functional requirements.
sections:
- id: development-agent-support
title: Development Agent Support
template: |
- Frontend development workflows
- Backend development workflows
- Full-stack integration
- Local development experience
- id: iac-development
title: Infrastructure-as-Code Development
template: |
- IaC development workflows
- Testing frameworks
- Deployment automation
- Version control integration
- id: cross-agent-collaboration
title: Cross-Agent Collaboration
template: |
- Shared services access
- Communication patterns
- Data sharing mechanisms
- Security boundaries
- id: cicd-integration-workflow
title: CI/CD Integration
type: code
language: yaml
template: |
stages:
- analyze
- plan
- architect
- develop
- test
- deploy
- id: platform-validation
title: Platform Validation & Testing
instruction: Execute comprehensive validation to ensure the platform meets all requirements.
sections:
- id: functional-testing
title: Functional Testing
template: |
- Component testing
- Integration testing
- End-to-end testing
- Performance testing
- id: security-validation
title: Security Validation
template: |
- Penetration testing
- Compliance scanning
- Vulnerability assessment
- Access control validation
- id: dr-testing
title: Disaster Recovery Testing
template: |
- Backup restoration
- Failover procedures
- Recovery time validation
- Data integrity checks
- id: load-testing
title: Load Testing
type: code
language: typescript
template: |
// K6 Load Test Example
import http from 'k6/http';
import { check } from 'k6';
export let options = {
stages: [
{ duration: '5m', target: {{target_users}} },
{ duration: '10m', target: {{target_users}} },
{ duration: '5m', target: 0 },
],
};
- id: knowledge-transfer
title: Knowledge Transfer & Documentation
instruction: Prepare comprehensive documentation and knowledge transfer materials.
sections:
- id: platform-documentation
title: Platform Documentation
template: |
- Architecture documentation
- Operational procedures
- Configuration reference
- API documentation
- id: training-materials
title: Training Materials
template: |
- Developer guides
- Operations training
- Security best practices
- Troubleshooting guides
- id: handoff-procedures
title: Handoff Procedures
template: |
- Team responsibilities
- Escalation procedures
- Support model
- Knowledge base
- id: implementation-review
title: Implementation Review with Architect
instruction: Document the post-implementation review session with the Architect to validate alignment and capture learnings.
sections:
- id: implementation-validation
title: Implementation Validation
template: |
- Architecture alignment verification
- Deviation documentation
- Performance validation
- Security review
- id: lessons-learned
title: Lessons Learned
template: |
- What went well
- Challenges encountered
- Process improvements
- Technical insights
- id: future-evolution
title: Future Evolution
template: |
- Enhancement opportunities
- Technical debt items
- Upgrade planning
- Capacity planning
- id: sign-off
title: Sign-off & Acceptance
template: |
- Architect approval
- Stakeholder acceptance
- Go-live authorization
- Support transition
- id: platform-metrics
title: Platform Metrics & KPIs
instruction: Define and implement key performance indicators for platform success measurement.
sections:
- id: technical-metrics
title: Technical Metrics
template: |
- Platform availability: {{availability_target}}
- Response time: {{response_time_target}}
- Resource utilization: {{utilization_target}}
- Error rates: {{error_rate_target}}
- id: business-metrics
title: Business Metrics
template: |
- Developer productivity
- Deployment frequency
- Lead time for changes
- Mean time to recovery
- id: operational-metrics
title: Operational Metrics
template: |
- Incident response time
- Patch compliance
- Cost per workload
- Resource efficiency
- id: appendices
title: Appendices
sections:
- id: config-reference
title: A. Configuration Reference
instruction: Document all configuration parameters and their values used in the platform implementation.
- id: troubleshooting
title: B. Troubleshooting Guide
instruction: Provide common issues and their resolutions for platform operations.
- id: security-controls
title: C. Security Controls Matrix
instruction: Map implemented security controls to compliance requirements.
- id: integration-points
title: D. Integration Points
instruction: Document all integration points with external systems and services.
- id: final-review
instruction: Final Review - Ensure all platform layers are properly implemented, integrated, and documented. Verify that the implementation fully supports the BMAD methodology and all agent workflows. Confirm successful validation against the infrastructure checklist.
content: |
---
_Platform Version: 1.0_
_Implementation Date: {{implementation_date}}_
_Next Review: {{review_date}}_
_Approved by: {{architect_name}} (Architect), {{devops_name}} (DevOps/Platform Engineer)_