Platform Integration
Overview
This skill provides concrete implementation guidance for mapping CMMI process areas to GitHub and Azure DevOps platform features.
Core principle: CMMI defines WHAT processes are required. This skill shows HOW to implement them in your platform with production-ready configurations.
Platforms covered:
- GitHub - Issues, PRs, Actions, Projects for CMMI implementation
- Azure DevOps - Work Items, Repos, Pipelines, Boards for CMMI implementation
When to Use
Use this skill when:
- Implementing requirements traceability in GitHub/Azure DevOps
- Setting up CI/CD pipelines with CMMI quality gates
- Configuring branch protection and code review policies
- Automating metrics collection for measurement
- Creating audit trails for compliance
- Migrating between platforms (GitHub ↔ Azure DevOps)
- Setting up risk tracking in work items
- Integrating CMMI processes with platform automation
Do NOT use for:
- CMMI process definitions → Use sdlc-prescription document
- Process-agnostic guidance → Use requirements-lifecycle, design-and-build, etc.
- Non-GitHub/Azure DevOps platforms → Adapt principles to your platform
Quick Reference: CMMI → Platform Mapping
| CMMI Process Area |
GitHub Feature |
Azure DevOps Feature |
Reference Sheet |
| REQM (Requirements Management) |
Issues, Projects, Labels |
Work Items, Queries, Backlogs |
github-requirements.md, azdo-requirements.md |
| CM (Configuration Management) |
Branch Protection, CODEOWNERS |
Branch Policies, Required Reviewers |
github-config-mgmt.md, azdo-config-mgmt.md |
| VER + VAL + PI (Quality) |
Actions, Status Checks, PRs |
Pipelines, Gates, Test Plans |
github-quality-gates.md, azdo-quality-gates.md |
| MA (Measurement) |
Insights, API, Actions |
Analytics, Dashboards, OData |
github-measurement.md, azdo-measurement.md |
| DAR + RSKM (Governance) |
Discussions, Wiki, Issues |
Wiki, Custom Work Items |
github-audit-trail.md, azdo-audit-trail.md |
Platform Selection Criteria
When to Use GitHub
Best for:
- Open source projects (public repositories)
- Developer-centric workflows (PRs, code review focus)
- Lightweight process (startups, small teams)
- Git-native workflows (GitFlow, GitHub Flow, trunk-based)
- Strong Actions ecosystem for automation
- Integration with third-party dev tools
Strengths:
- ✅ Excellent developer experience
- ✅ Free for public repositories
- ✅ Strong community and marketplace
- ✅ Simple, intuitive UI
- ✅ Best-in-class code review
- ✅ Actions for flexible automation
Limitations:
- ❌ Limited work item hierarchy (no built-in epic → feature → story)
- ❌ Basic project management features
- ❌ Limited reporting/analytics (compared to Azure DevOps)
- ❌ No built-in test management
- ❌ Weaker audit logging (for compliance)
CMMI Maturity:
- Level 2: Fully capable
- Level 3: Fully capable with third-party tools
- Level 4: Limited (external analytics tools needed)
When to Use Azure DevOps
Best for:
- Enterprise projects (regulated industries)
- Complex work item hierarchies (epic → feature → story)
- Integrated ALM (requirements → design → test → deploy)
- Advanced reporting and analytics
- Compliance and audit requirements
- Microsoft stack integration (.NET, Azure)
Strengths:
- ✅ Rich work item management
- ✅ Built-in test management
- ✅ Advanced analytics and reporting
- ✅ Audit logging for compliance
- ✅ Integrated CI/CD with environments
- ✅ Customizable processes
Limitations:
- ❌ Steeper learning curve
- ❌ More complex to configure
- ❌ Less developer-friendly UX
- ❌ Weaker community/marketplace
- ❌ Limited free tier
CMMI Maturity:
- Level 2: Fully capable
- Level 3: Fully capable (native features)
- Level 4: Fully capable (native analytics, baselines)
Hybrid Scenarios
Common patterns:
- GitHub + Azure DevOps Boards: Code in GitHub, work tracking in Azure DevOps
- Azure DevOps + GitHub Actions: Work items in Azure DevOps, CI/CD in GitHub
- Multi-Platform: Microservices split across platforms
Integration options:
- Azure Boards + GitHub integration (official)
- Zapier/Make for workflow automation
- API-based synchronization
- Third-party tools (Unito, Workato)
Reference Sheets
The following reference sheets provide detailed, production-ready implementation guidance for each platform.
GitHub Integration (5 Sheets)
1. Requirements Management in GitHub
When to use: Implementing REQM (Requirements Management) in GitHub
→ See github-requirements.md
Covers:
- Issue templates for requirements with traceability IDs
- Label strategy for requirement types and states
- Projects/Milestones for requirement organization
- PR linking patterns (
Implements #123, Closes #456)
- Traceability matrix automation
- Requirement change management workflow
- Level 2/3/4 scaling requirements
- Audit trail for requirements changes
2. Configuration Management in GitHub
When to use: Implementing CM (Configuration Management) in GitHub
→ See github-config-mgmt.md
Covers:
- Branch protection rules (required reviewers, status checks)
- CODEOWNERS file format and enforcement
- Git workflow comparison (GitFlow, GitHub Flow, trunk-based)
- Merge strategies (squash, merge, rebase) trade-offs
- Baseline management (tags, releases)
- Release management automation
- Emergency hotfix procedures
- Configuration as code (settings.yml, Terraform)
3. Quality Gates in GitHub
When to use: Implementing VER, VAL, PI (Verification, Validation, Integration) in GitHub
→ See github-quality-gates.md
Covers:
- GitHub Actions workflows for CI/CD
- Multi-stage pipelines (build → test → deploy)
- Required status checks configuration
- Test execution and coverage enforcement
- Deployment environments and protection rules
- Approval workflows for production
- Quality metrics collection
- Integration testing strategies
4. Measurement in GitHub
When to use: Implementing MA (Measurement & Analysis) in GitHub
→ See github-measurement.md
Covers:
- GitHub Insights and API for metrics
- DORA metrics implementation (all 4 metrics)
- Metrics collection automation (Actions)
- Dashboard creation (external tools integration)
- Historical baseline tracking
- Statistical process control (Level 4)
- Alerting on metric thresholds
- Custom metrics for project needs
5. Audit Trail in GitHub
When to use: Compliance and audit requirements in GitHub
→ See github-audit-trail.md
Covers:
- Commit history as audit log
- PR review history retention
- Issue comment trails
- Action logs and artifact retention
- Compliance mappings (SOC 2, ISO, GDPR)
- Audit report generation
- Data retention policies
- Access control for sensitive data
Azure DevOps Integration (5 Sheets)
6. Requirements Management in Azure DevOps
When to use: Implementing REQM (Requirements Management) in Azure DevOps
→ See azdo-requirements.md
Covers:
- Work item types (Epic, Feature, User Story, Requirement)
- Custom fields for traceability
- Backlogs and boards configuration
- Queries for requirement reporting
- Multi-level hierarchy management
- Change request workflow
- Requirement baseline management
- Integration with test plans
7. Configuration Management in Azure DevOps
When to use: Implementing CM (Configuration Management) in Azure DevOps
→ See azdo-config-mgmt.md
Covers:
- Azure Repos branch policies
- Required reviewers and CODEOWNERS
- Linked work items enforcement
- Merge strategies and build validation
- Release management with environments
- Baseline tagging automation
- TFVC migration (if needed)
- Configuration as code (YAML pipelines)
8. Quality Gates in Azure DevOps
When to use: Implementing VER, VAL, PI (Verification, Validation, Integration) in Azure DevOps
→ See azdo-quality-gates.md
Covers:
- Azure Pipelines multi-stage YAML
- Quality gates between stages
- Test Plans integration
- Approval workflows and gates
- Deployment environments
- Release management strategies
- Test execution and reporting
- Quality metrics tracking
9. Measurement in Azure DevOps
When to use: Implementing MA (Measurement & Analysis) in Azure DevOps
→ See azdo-measurement.md
Covers:
- Analytics views and widgets
- Dashboard creation and customization
- OData queries for custom reports
- PowerBI integration
- DORA metrics implementation
- Process baselines (Level 3/4)
- Historical data analysis
- Statistical process control
10. Audit Trail in Azure DevOps
When to use: Compliance and audit requirements in Azure DevOps
→ See azdo-audit-trail.md
Covers:
- Work item history and revisions
- Audit logs (admin actions, permission changes)
- Pipeline run history retention
- Compliance features (data residency, encryption)
- Audit report generation
- Retention policies configuration
- Access control and permissions
- Regulatory compliance (FDA, ISO, SOC 2)
Common Mistakes
| Mistake |
Why It Fails |
Better Approach |
| Treating platform as CMMI-aware |
Platforms don't enforce CMMI; you configure enforcement |
Map each CMMI practice to platform feature explicitly |
| Using platform defaults |
Defaults are permissive (no quality gates, no reviews) |
Configure branch protection, required checks, policies |
| Manual traceability |
Spreadsheet traceability becomes stale immediately |
Automate with issue/PR links, work item queries, API |
| Skipping audit trail setup |
Compliance failures discovered during audit |
Configure retention, access logs, history from project start |
| One-size-fits-all configuration |
Level 2 project gets Level 4 overhead (or vice versa) |
Scale configuration based on CMMI target level |
| Forgetting baselines |
No way to freeze requirements or code for releases |
Implement baseline tagging, release branches, milestone freezes |
| Ignoring platform limitations |
GitHub weak at test management; Azure DevOps weak at code review |
Use hybrid approach or third-party tools for gaps |
| No verification automation |
Traceability breaks without detection |
Scheduled checks for orphaned requirements, missing links |
| Generic metrics |
Collecting data nobody uses |
GQM approach: Goal → Question → Metric (actionable only) |
| Missing cross-process links |
Requirements don't link to risks; tests don't link to design |
Document integration patterns in configuration |
Integration with Other Skills
| When You're Doing |
Also Use |
For |
| Platform setup for requirements |
requirements-lifecycle |
REQM/RD process definitions |
| Platform setup for CI/CD |
design-and-build |
TS/PI process definitions |
| Platform setup for testing |
quality-assurance |
VER/VAL process definitions |
| Platform setup for metrics |
quantitative-management |
MA/QPM metrics definitions |
| Platform selection decision |
governance-and-risk |
Decision analysis for platform choice |
| Initial platform adoption |
lifecycle-adoption |
Incremental rollout strategy |
Next Steps
- Determine your platform: GitHub, Azure DevOps, or hybrid
- Identify CMMI process area: Which process (REQM, CM, VER, etc.) are you implementing?
- Check target maturity level: Level 2, 3, or 4 (from CLAUDE.md or user)
- Load reference sheet: Read platform-specific implementation guide
- Apply configuration: Use production-ready examples from reference sheet
- Verify setup: Run verification checks for traceability, quality gates, audit trail
- Integrate processes: Link requirements → code → tests → metrics
Remember: Platforms don't enforce CMMI compliance automatically. You must configure them to implement CMMI practices. This skill provides the configuration patterns to bridge CMMI policy to platform reality.
1---2name: platform-integration3description: Use when implementing CMMI processes in GitHub or Azure DevOps, migrating between platforms, or establishing traceability/compliance on GitHub/Azure - platform-specific process guidance4---56# Platform Integration78## Overview910This skill provides concrete implementation guidance for mapping CMMI process areas to GitHub and Azure DevOps platform features.1112**Core principle**: CMMI defines WHAT processes are required. This skill shows HOW to implement them in your platform with production-ready configurations.1314**Platforms covered**:15- **GitHub** - Issues, PRs, Actions, Projects for CMMI implementation16- **Azure DevOps** - Work Items, Repos, Pipelines, Boards for CMMI implementation1718---1920## When to Use2122Use this skill when:23- Implementing requirements traceability in GitHub/Azure DevOps24- Setting up CI/CD pipelines with CMMI quality gates25- Configuring branch protection and code review policies26- Automating metrics collection for measurement27- Creating audit trails for compliance28- Migrating between platforms (GitHub ↔ Azure DevOps)29- Setting up risk tracking in work items30- Integrating CMMI processes with platform automation3132**Do NOT use for**:33- CMMI process definitions → Use sdlc-prescription document34- Process-agnostic guidance → Use requirements-lifecycle, design-and-build, etc.35- Non-GitHub/Azure DevOps platforms → Adapt principles to your platform3637---3839## Quick Reference: CMMI → Platform Mapping4041| CMMI Process Area | GitHub Feature | Azure DevOps Feature | Reference Sheet |42|-------------------|----------------|----------------------|-----------------|43| **REQM (Requirements Management)** | Issues, Projects, Labels | Work Items, Queries, Backlogs | github-requirements.md, azdo-requirements.md |44| **CM (Configuration Management)** | Branch Protection, CODEOWNERS | Branch Policies, Required Reviewers | github-config-mgmt.md, azdo-config-mgmt.md |45| **VER + VAL + PI (Quality)** | Actions, Status Checks, PRs | Pipelines, Gates, Test Plans | github-quality-gates.md, azdo-quality-gates.md |46| **MA (Measurement)** | Insights, API, Actions | Analytics, Dashboards, OData | github-measurement.md, azdo-measurement.md |47| **DAR + RSKM (Governance)** | Discussions, Wiki, Issues | Wiki, Custom Work Items | github-audit-trail.md, azdo-audit-trail.md |4849---5051## Platform Selection Criteria5253### When to Use GitHub5455**Best for**:56- Open source projects (public repositories)57- Developer-centric workflows (PRs, code review focus)58- Lightweight process (startups, small teams)59- Git-native workflows (GitFlow, GitHub Flow, trunk-based)60- Strong Actions ecosystem for automation61- Integration with third-party dev tools6263**Strengths**:64- ✅ Excellent developer experience65- ✅ Free for public repositories66- ✅ Strong community and marketplace67- ✅ Simple, intuitive UI68- ✅ Best-in-class code review69- ✅ Actions for flexible automation7071**Limitations**:72- ❌ Limited work item hierarchy (no built-in epic → feature → story)73- ❌ Basic project management features74- ❌ Limited reporting/analytics (compared to Azure DevOps)75- ❌ No built-in test management76- ❌ Weaker audit logging (for compliance)7778**CMMI Maturity**:79- **Level 2**: Fully capable80- **Level 3**: Fully capable with third-party tools81- **Level 4**: Limited (external analytics tools needed)8283### When to Use Azure DevOps8485**Best for**:86- Enterprise projects (regulated industries)87- Complex work item hierarchies (epic → feature → story)88- Integrated ALM (requirements → design → test → deploy)89- Advanced reporting and analytics90- Compliance and audit requirements91- Microsoft stack integration (.NET, Azure)9293**Strengths**:94- ✅ Rich work item management95- ✅ Built-in test management96- ✅ Advanced analytics and reporting97- ✅ Audit logging for compliance98- ✅ Integrated CI/CD with environments99- ✅ Customizable processes100101**Limitations**:102- ❌ Steeper learning curve103- ❌ More complex to configure104- ❌ Less developer-friendly UX105- ❌ Weaker community/marketplace106- ❌ Limited free tier107108**CMMI Maturity**:109- **Level 2**: Fully capable110- **Level 3**: Fully capable (native features)111- **Level 4**: Fully capable (native analytics, baselines)112113### Hybrid Scenarios114115**Common patterns**:116- **GitHub + Azure DevOps Boards**: Code in GitHub, work tracking in Azure DevOps117- **Azure DevOps + GitHub Actions**: Work items in Azure DevOps, CI/CD in GitHub118- **Multi-Platform**: Microservices split across platforms119120**Integration options**:121- Azure Boards + GitHub integration (official)122- Zapier/Make for workflow automation123- API-based synchronization124- Third-party tools (Unito, Workato)125126---127128## Reference Sheets129130The following reference sheets provide detailed, production-ready implementation guidance for each platform.131132### GitHub Integration (5 Sheets)133134#### 1. Requirements Management in GitHub135136**When to use**: Implementing REQM (Requirements Management) in GitHub137138→ See [github-requirements.md](./github-requirements.md)139140**Covers**:141- Issue templates for requirements with traceability IDs142- Label strategy for requirement types and states143- Projects/Milestones for requirement organization144- PR linking patterns (`Implements #123`, `Closes #456`)145- Traceability matrix automation146- Requirement change management workflow147- Level 2/3/4 scaling requirements148- Audit trail for requirements changes149150#### 2. Configuration Management in GitHub151152**When to use**: Implementing CM (Configuration Management) in GitHub153154→ See [github-config-mgmt.md](./github-config-mgmt.md)155156**Covers**:157- Branch protection rules (required reviewers, status checks)158- CODEOWNERS file format and enforcement159- Git workflow comparison (GitFlow, GitHub Flow, trunk-based)160- Merge strategies (squash, merge, rebase) trade-offs161- Baseline management (tags, releases)162- Release management automation163- Emergency hotfix procedures164- Configuration as code (settings.yml, Terraform)165166#### 3. Quality Gates in GitHub167168**When to use**: Implementing VER, VAL, PI (Verification, Validation, Integration) in GitHub169170→ See [github-quality-gates.md](./github-quality-gates.md)171172**Covers**:173- GitHub Actions workflows for CI/CD174- Multi-stage pipelines (build → test → deploy)175- Required status checks configuration176- Test execution and coverage enforcement177- Deployment environments and protection rules178- Approval workflows for production179- Quality metrics collection180- Integration testing strategies181182#### 4. Measurement in GitHub183184**When to use**: Implementing MA (Measurement & Analysis) in GitHub185186→ See [github-measurement.md](./github-measurement.md)187188**Covers**:189- GitHub Insights and API for metrics190- DORA metrics implementation (all 4 metrics)191- Metrics collection automation (Actions)192- Dashboard creation (external tools integration)193- Historical baseline tracking194- Statistical process control (Level 4)195- Alerting on metric thresholds196- Custom metrics for project needs197198#### 5. Audit Trail in GitHub199200**When to use**: Compliance and audit requirements in GitHub201202→ See [github-audit-trail.md](./github-audit-trail.md)203204**Covers**:205- Commit history as audit log206- PR review history retention207- Issue comment trails208- Action logs and artifact retention209- Compliance mappings (SOC 2, ISO, GDPR)210- Audit report generation211- Data retention policies212- Access control for sensitive data213214### Azure DevOps Integration (5 Sheets)215216#### 6. Requirements Management in Azure DevOps217218**When to use**: Implementing REQM (Requirements Management) in Azure DevOps219220→ See [azdo-requirements.md](./azdo-requirements.md)221222**Covers**:223- Work item types (Epic, Feature, User Story, Requirement)224- Custom fields for traceability225- Backlogs and boards configuration226- Queries for requirement reporting227- Multi-level hierarchy management228- Change request workflow229- Requirement baseline management230- Integration with test plans231232#### 7. Configuration Management in Azure DevOps233234**When to use**: Implementing CM (Configuration Management) in Azure DevOps235236→ See [azdo-config-mgmt.md](./azdo-config-mgmt.md)237238**Covers**:239- Azure Repos branch policies240- Required reviewers and CODEOWNERS241- Linked work items enforcement242- Merge strategies and build validation243- Release management with environments244- Baseline tagging automation245- TFVC migration (if needed)246- Configuration as code (YAML pipelines)247248#### 8. Quality Gates in Azure DevOps249250**When to use**: Implementing VER, VAL, PI (Verification, Validation, Integration) in Azure DevOps251252→ See [azdo-quality-gates.md](./azdo-quality-gates.md)253254**Covers**:255- Azure Pipelines multi-stage YAML256- Quality gates between stages257- Test Plans integration258- Approval workflows and gates259- Deployment environments260- Release management strategies261- Test execution and reporting262- Quality metrics tracking263264#### 9. Measurement in Azure DevOps265266**When to use**: Implementing MA (Measurement & Analysis) in Azure DevOps267268→ See [azdo-measurement.md](./azdo-measurement.md)269270**Covers**:271- Analytics views and widgets272- Dashboard creation and customization273- OData queries for custom reports274- PowerBI integration275- DORA metrics implementation276- Process baselines (Level 3/4)277- Historical data analysis278- Statistical process control279280#### 10. Audit Trail in Azure DevOps281282**When to use**: Compliance and audit requirements in Azure DevOps283284→ See [azdo-audit-trail.md](./azdo-audit-trail.md)285286**Covers**:287- Work item history and revisions288- Audit logs (admin actions, permission changes)289- Pipeline run history retention290- Compliance features (data residency, encryption)291- Audit report generation292- Retention policies configuration293- Access control and permissions294- Regulatory compliance (FDA, ISO, SOC 2)295296---297298## Common Mistakes299300| Mistake | Why It Fails | Better Approach |301|---------|--------------|-----------------|302| **Treating platform as CMMI-aware** | Platforms don't enforce CMMI; you configure enforcement | Map each CMMI practice to platform feature explicitly |303| **Using platform defaults** | Defaults are permissive (no quality gates, no reviews) | Configure branch protection, required checks, policies |304| **Manual traceability** | Spreadsheet traceability becomes stale immediately | Automate with issue/PR links, work item queries, API |305| **Skipping audit trail setup** | Compliance failures discovered during audit | Configure retention, access logs, history from project start |306| **One-size-fits-all configuration** | Level 2 project gets Level 4 overhead (or vice versa) | Scale configuration based on CMMI target level |307| **Forgetting baselines** | No way to freeze requirements or code for releases | Implement baseline tagging, release branches, milestone freezes |308| **Ignoring platform limitations** | GitHub weak at test management; Azure DevOps weak at code review | Use hybrid approach or third-party tools for gaps |309| **No verification automation** | Traceability breaks without detection | Scheduled checks for orphaned requirements, missing links |310| **Generic metrics** | Collecting data nobody uses | GQM approach: Goal → Question → Metric (actionable only) |311| **Missing cross-process links** | Requirements don't link to risks; tests don't link to design | Document integration patterns in configuration |312313---314315## Integration with Other Skills316317| When You're Doing | Also Use | For |318|-------------------|----------|-----|319| Platform setup for requirements | `requirements-lifecycle` | REQM/RD process definitions |320| Platform setup for CI/CD | `design-and-build` | TS/PI process definitions |321| Platform setup for testing | `quality-assurance` | VER/VAL process definitions |322| Platform setup for metrics | `quantitative-management` | MA/QPM metrics definitions |323| Platform selection decision | `governance-and-risk` | Decision analysis for platform choice |324| Initial platform adoption | `lifecycle-adoption` | Incremental rollout strategy |325326---327328## Next Steps3293301. **Determine your platform**: GitHub, Azure DevOps, or hybrid3312. **Identify CMMI process area**: Which process (REQM, CM, VER, etc.) are you implementing?3323. **Check target maturity level**: Level 2, 3, or 4 (from CLAUDE.md or user)3334. **Load reference sheet**: Read platform-specific implementation guide3345. **Apply configuration**: Use production-ready examples from reference sheet3356. **Verify setup**: Run verification checks for traceability, quality gates, audit trail3367. **Integrate processes**: Link requirements → code → tests → metrics337338**Remember**: Platforms don't enforce CMMI compliance automatically. You must configure them to implement CMMI practices. This skill provides the configuration patterns to bridge CMMI policy to platform reality.