| name | platform-integration |
| description | Use when implementing CMMI processes in GitHub or Azure DevOps, migrating between platforms, or establishing traceability/compliance on GitHub/Azure - platform-specific process guidance |
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.
