294 lines
6.0 KiB
Markdown
294 lines
6.0 KiB
Markdown
# VCS Adaptation Examples
|
|
|
|
## Real-World Scenarios: How BMAD Adapts
|
|
|
|
### Example 1: Startup with GitHub Flow
|
|
|
|
**Context:** 5-person team, web SaaS, deploys daily
|
|
|
|
**Discovery:**
|
|
|
|
```
|
|
BMAD: "How does your team manage code versions?"
|
|
User: "Git with GitHub"
|
|
BMAD: "Which Git workflow best describes your approach?"
|
|
User: "GitHub Flow - simple feature branches"
|
|
```
|
|
|
|
**BMAD Adapts:**
|
|
|
|
- Architect generates lightweight, PR-sized architecture updates
|
|
- SM creates 1-3 day stories that map to single PRs
|
|
- Dev suggests branch names like `feature/add-user-auth`
|
|
- All docs optimized for quick review in PR comments
|
|
|
|
**Generated Architecture Snippet:**
|
|
|
|
```markdown
|
|
## Payment Service Update
|
|
|
|
_PR: #234 - feature/add-stripe-integration_
|
|
|
|
### Changes in This PR
|
|
|
|
- New Stripe webhook handler
|
|
- Updated payment models
|
|
- Added retry logic
|
|
|
|
### Testing
|
|
|
|
- [ ] Unit tests for webhook handler
|
|
- [ ] Integration test with Stripe test mode
|
|
- [ ] Manual testing checklist in PR
|
|
```
|
|
|
|
---
|
|
|
|
### Example 2: Enterprise with GitFlow
|
|
|
|
**Context:** 50-person team, banking software, quarterly releases
|
|
|
|
**Discovery:**
|
|
|
|
```
|
|
BMAD: "How does your team manage code versions?"
|
|
User: "Git with corporate server"
|
|
BMAD: "Which Git workflow?"
|
|
User: "GitFlow - we have develop, release, and hotfix branches"
|
|
```
|
|
|
|
**BMAD Adapts:**
|
|
|
|
- Architect creates version-oriented architecture docs
|
|
- PM generates release-scoped PRDs
|
|
- SM groups stories by release version
|
|
- Dev follows strict branch naming
|
|
|
|
**Generated Architecture Snippet:**
|
|
|
|
```markdown
|
|
## Release 2.4.0 Architecture
|
|
|
|
### Version Highlights
|
|
|
|
- New authentication system (breaking change)
|
|
- Performance improvements
|
|
- Database migration required
|
|
|
|
### Branch Status
|
|
|
|
- develop: v2.5.0 features in progress
|
|
- release/2.4.0: Final testing
|
|
- hotfix/2.3.1: Critical fix for production
|
|
|
|
### Migration Guide
|
|
|
|
From 2.3.x to 2.4.0:
|
|
|
|
1. Run migration script
|
|
2. Update config files
|
|
3. Restart services in order
|
|
```
|
|
|
|
---
|
|
|
|
### Example 3: No Version Control
|
|
|
|
**Context:** Data scientist, one-time analysis script
|
|
|
|
**Discovery:**
|
|
|
|
```
|
|
BMAD: "How does your team manage code versions?"
|
|
User: "No version control needed - this is a one-time script"
|
|
```
|
|
|
|
**BMAD Adapts:**
|
|
|
|
- All code in single, runnable package
|
|
- Extensive inline documentation
|
|
- No commit messages or branch references
|
|
- Date-stamped delivery
|
|
|
|
**Generated Package:**
|
|
|
|
```
|
|
customer_analysis_20240315/
|
|
├── README.md # Complete instructions
|
|
├── requirements.txt # All Python dependencies
|
|
├── analysis.py # Full script with comments
|
|
├── data/
|
|
│ └── sample.csv # Sample data format
|
|
└── output/
|
|
└── results_template.xlsx
|
|
```
|
|
|
|
**README Content:**
|
|
|
|
```markdown
|
|
# Customer Analysis Script
|
|
|
|
Generated: 2024-03-15
|
|
|
|
## Quick Start
|
|
|
|
1. Install dependencies: pip install -r requirements.txt
|
|
2. Place your data in data/input.csv
|
|
3. Run: python analysis.py
|
|
4. Results appear in output/
|
|
|
|
## No Version Control Required
|
|
|
|
This is a complete, self-contained package.
|
|
```
|
|
|
|
---
|
|
|
|
### Example 4: Custom SVN Workflow
|
|
|
|
**Context:** Game studio using Subversion
|
|
|
|
**Discovery:**
|
|
|
|
```
|
|
BMAD: "How does your team manage code versions?"
|
|
User: "Other version control system"
|
|
BMAD: "Which system?"
|
|
User: "Subversion (SVN)"
|
|
```
|
|
|
|
**BMAD Adapts:**
|
|
|
|
- Uses "revision" instead of "commit"
|
|
- References trunk/branches/tags structure
|
|
- Revision numbers, not hashes
|
|
- SVN-specific commands
|
|
|
|
**Generated Instructions:**
|
|
|
|
```markdown
|
|
## Integration Steps
|
|
|
|
1. Update your working copy:
|
|
svn update
|
|
|
|
2. Create feature branch:
|
|
svn copy ^/trunk ^/branches/feature-player-inventory
|
|
|
|
3. After implementation:
|
|
svn merge ^/branches/feature-player-inventory
|
|
|
|
4. Commit with revision message:
|
|
svn commit -m "Add player inventory system (refs ticket #456)"
|
|
```
|
|
|
|
---
|
|
|
|
### Example 5: Trunk-Based with Feature Flags
|
|
|
|
**Context:** Netflix-style continuous deployment
|
|
|
|
**Discovery:**
|
|
|
|
```
|
|
BMAD: "How does your team manage code versions?"
|
|
User: "Git with GitHub"
|
|
BMAD: "Which Git workflow?"
|
|
User: "Trunk-Based - we deploy continuously"
|
|
```
|
|
|
|
**BMAD Adapts:**
|
|
|
|
- Everything behind feature flags
|
|
- Tiny, hours-long tasks
|
|
- Direct commits or same-day PRs
|
|
- Progressive rollout plans
|
|
|
|
**Generated Story:**
|
|
|
|
````markdown
|
|
## Story: Add Recommendation Engine
|
|
|
|
Size: 4 hours
|
|
Flag: `recommendation-engine-v2`
|
|
|
|
### Implementation
|
|
|
|
```python
|
|
if feature_flag.is_enabled("recommendation-engine-v2", user_id):
|
|
return new_recommendation_engine(user_id)
|
|
else:
|
|
return legacy_recommendations(user_id)
|
|
```
|
|
````
|
|
|
|
### Rollout Plan
|
|
|
|
- Hour 1-2: Implement behind flag (0% users)
|
|
- Hour 3: Deploy and enable for employees
|
|
- Hour 4: Enable for 1% external users
|
|
- Day 2: 10% if metrics good
|
|
- Day 3: 50%
|
|
- Day 5: 100% and schedule flag removal
|
|
|
|
```
|
|
|
|
---
|
|
|
|
### Example 6: Complex Multi-VCS Setup
|
|
|
|
**Context:** Enterprise with mixed systems
|
|
|
|
**Discovery:**
|
|
```
|
|
|
|
BMAD: "How does your team manage code versions?"
|
|
User: "Custom/Complex setup"
|
|
BMAD: "Please describe:"
|
|
User: "Frontend in Git, backend in Perforce, configs in SVN"
|
|
|
|
````
|
|
|
|
**BMAD Adapts:**
|
|
- Asks for component-specific preferences
|
|
- Generates VCS-appropriate artifacts per component
|
|
- Uses neutral terminology in cross-component docs
|
|
|
|
**Generated Guidance:**
|
|
```markdown
|
|
## Multi-VCS Development Guide
|
|
|
|
### Frontend (Git/GitHub Flow)
|
|
- Feature branches from main
|
|
- PR review process
|
|
- Deploy on merge
|
|
|
|
### Backend (Perforce)
|
|
- Create changelist for features
|
|
- Submit after review
|
|
- Changelist numbers in deployment notes
|
|
|
|
### Configuration (SVN)
|
|
- Update from trunk before changes
|
|
- Commit with revision references
|
|
- Tag for production releases
|
|
|
|
### Cross-Component Changes
|
|
When updating across systems:
|
|
1. Frontend PR: #123
|
|
2. Backend Changelist: 456789
|
|
3. Config Revision: r1234
|
|
|
|
Reference all three in deployment ticket.
|
|
````
|
|
|
|
## Key Takeaways
|
|
|
|
1. **BMAD never assumes** - always discovers first
|
|
2. **Adapts terminology** - commit/changelist/revision as appropriate
|
|
3. **Respects workflows** - doesn't try to "improve" existing processes
|
|
4. **Practical focus** - generates what works with their tools
|
|
5. **Clear communication** - uses the team's language
|
|
|
|
This flexibility makes BMAD valuable to ANY team, regardless of their VCS choice.
|