UNPKG

@cloudkinetix/bmad-enhanced

Version:

Cloud-Kinetix enhanced fork of BMAD-METHOD - Breakthrough Method of Agile AI-driven Development with robust versioning and unified validation.

231 lines (162 loc) 5.68 kB
# Conflict Resolution Strategies for Parallel Development ## Overview This guide provides strategies for preventing, detecting, and resolving conflicts in parallel development workflows. ## Conflict Prevention Strategies ### 1. Architectural Boundaries **Prevention Level**: ★★★★★ (5/5) - **Module Isolation**: Keep features in separate modules/packages - **Interface Contracts**: Define clear APIs between components - **Dependency Injection**: Reduce tight coupling - **Event-Driven Architecture**: Use events for cross-feature communication ### 2. Code Organization **Prevention Level**: ★★★★☆ (4/5) ``` project/ ├── features/ │ ├── auth/ # Team 1 workspace │ ├── dashboard/ # Team 2 workspace │ └── reports/ # Team 3 workspace ├── shared/ │ ├── components/ # Versioned shared code │ └── utils/ # Stable utilities └── core/ # Rarely changed foundation ``` ### 3. Git Strategies **Prevention Level**: ★★★★☆ (4/5) - **Feature Flags**: Decouple deployment from release - **Branch Protection**: Require reviews for shared code - **Atomic Commits**: Small, focused changes - **Semantic Commits**: Clear change documentation ## Conflict Detection Techniques ### 1. Early Warning Systems #### Automated Conflict Detection ```bash # Run in CI/CD pipeline git worktree add -b test-merge ../test-merge cd ../test-merge git merge --no-commit --no-ff parallel/feature-1 parallel/feature-2 if [ $? -ne 0 ]; then echo "WARNING: Conflicts detected between features" fi ``` #### Semantic Analysis - **Code Purpose Overlap**: LLM analysis of functional overlap - **Data Flow Conflicts**: Trace data dependencies - **API Contract Violations**: Schema compatibility checks ### 2. Real-Time Monitoring **Conflict Dashboard Metrics**: - File modification overlap - Function/class name collisions - Import dependency cycles - Test data conflicts ## Conflict Resolution Workflows ### 1. The Three-Way Resolution **Effectiveness**: ★★★★☆ (4/5) ``` Original (main) ──┬── Feature A (changes X) └── Feature B (changes Y) Resolution: 1. Understand intent of both changes 2. Merge semantic purpose, not just code 3. Validate combined functionality 4. Update tests for new behavior ``` ### 2. The Mediator Pattern **Effectiveness**: ★★★★★ (5/5) When conflicts are complex: 1. **Assign Mediator**: Senior dev or architect 2. **Joint Session**: Both teams explain changes 3. **Design Solution**: Create unified approach 4. **Pair Implementation**: Both teams implement together 5. **Shared Ownership**: Both teams review final code ### 3. The Rollback-and-Retry **Effectiveness**: ★★★☆☆ (3/5) - Last resort When conflicts are severe: 1. Rollback one feature to stable state 2. Merge the other feature completely 3. Reimplement first feature with new context 4. Learn and document the issue ## Resolution Decision Tree ``` Conflict Detected │ ├─ Is it a simple file conflict? │ ├─ YES → Use git merge tools │ └─ NO → Continue │ ├─ Is it a semantic conflict? │ ├─ YES → Use Mediator Pattern │ └─ NO → Continue │ ├─ Is it an architectural conflict? │ ├─ YES → Escalate to architect │ └─ NO → Continue │ └─ Is it a business logic conflict? ├─ YES → Involve Product Owner └─ NO → Use Three-Way Resolution ``` ## Common Conflict Scenarios ### 1. Shared Configuration Files **Problem**: Multiple teams updating config **Solution**: - Configuration as code with schemas - Environment-specific overrides - Feature-specific config sections ### 2. Database Schema Conflicts **Problem**: Incompatible migrations **Solution**: - Numbered migration files - Backward-compatible changes only - Schema versioning strategy ### 3. Test Data Conflicts **Problem**: Shared test fixtures modified **Solution**: - Test data factories - Feature-specific test data - Isolated test databases ### 4. CSS/Style Conflicts **Problem**: Global styles collision **Solution**: - CSS modules or styled-components - BEM naming convention - Component-scoped styles ## Conflict Resolution Tools ### 1. Git Tools - `git mergetool` - Visual merge resolution - `git rerere` - Reuse recorded resolutions - `git bisect` - Find breaking changes ### 2. IDE Integration - VS Code Merge Editor - IntelliJ Conflict Resolution - Sublime Merge ### 3. Specialized Tools - Semantic Merge - Language-aware merging - Beyond Compare - Advanced diff/merge - P4Merge - Visual three-way merge ## Post-Conflict Actions ### 1. Documentation - Document resolution rationale - Update architecture decisions - Add to team knowledge base ### 2. Process Improvement - Analyze root cause - Update prevention strategies - Share learnings in retrospective ### 3. Test Enhancement - Add tests for merged behavior - Verify no regressions - Update integration tests ## Conflict Metrics to Track 1. **Frequency**: Conflicts per sprint 2. **Resolution Time**: Hours to resolve 3. **Severity**: Lines of code affected 4. **Recurrence**: Same conflict types 5. **Team Impact**: Developer hours lost ## Best Practices Summary 1. **Prevent First**: Architecture > Process > Tools 2. **Detect Early**: Automated checks in CI/CD 3. **Resolve Quickly**: Don't let conflicts linger 4. **Learn Always**: Every conflict is a learning opportunity 5. **Communicate More**: Over-communication prevents conflicts Remember: Conflicts are not failures - they're opportunities to improve your parallel development process!