tachyon-beep/platform-integration

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

1. Determine your platform: GitHub, Azure DevOps, or hybrid
2. Identify CMMI process area: Which process (REQM, CM, VER, etc.) are you implementing?
3. Check target maturity level: Level 2, 3, or 4 (from CLAUDE.md or user)
4. Load reference sheet: Read platform-specific implementation guide
5. Apply configuration: Use production-ready examples from reference sheet
6. Verify setup: Run verification checks for traceability, quality gates, audit trail
7. 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.