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
Reference: See docs/sdlc-prescription-cmmi-levels-2-4.md for CMMI process area definitions.
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---5
6# Platform Integration
7
8## Overview
9
10This skill provides concrete implementation guidance for mapping CMMI process areas to GitHub and Azure DevOps platform features.
11
12**Core principle**: CMMI defines WHAT processes are required. This skill shows HOW to implement them in your platform with production-ready configurations.
13
14**Platforms covered**:
15- **GitHub** - Issues, PRs, Actions, Projects for CMMI implementation
16- **Azure DevOps** - Work Items, Repos, Pipelines, Boards for CMMI implementation
17
18**Reference**: See `docs/sdlc-prescription-cmmi-levels-2-4.md` for CMMI process area definitions.
19
20---
21
22## When to Use
23
24Use this skill when:
25- Implementing requirements traceability in GitHub/Azure DevOps
26- Setting up CI/CD pipelines with CMMI quality gates
27- Configuring branch protection and code review policies
28- Automating metrics collection for measurement
29- Creating audit trails for compliance
30- Migrating between platforms (GitHub ↔ Azure DevOps)
31- Setting up risk tracking in work items
32- Integrating CMMI processes with platform automation
33
34**Do NOT use for**:
35- CMMI process definitions → Use sdlc-prescription document
36- Process-agnostic guidance → Use requirements-lifecycle, design-and-build, etc.
37- Non-GitHub/Azure DevOps platforms → Adapt principles to your platform
38
39---
40
41## Quick Reference: CMMI → Platform Mapping
42
43| CMMI Process Area | GitHub Feature | Azure DevOps Feature | Reference Sheet |
44|-------------------|----------------|----------------------|-----------------|
45| **REQM (Requirements Management)** | Issues, Projects, Labels | Work Items, Queries, Backlogs | github-requirements.md, azdo-requirements.md |
46| **CM (Configuration Management)** | Branch Protection, CODEOWNERS | Branch Policies, Required Reviewers | github-config-mgmt.md, azdo-config-mgmt.md |
47| **VER + VAL + PI (Quality)** | Actions, Status Checks, PRs | Pipelines, Gates, Test Plans | github-quality-gates.md, azdo-quality-gates.md |
48| **MA (Measurement)** | Insights, API, Actions | Analytics, Dashboards, OData | github-measurement.md, azdo-measurement.md |
49| **DAR + RSKM (Governance)** | Discussions, Wiki, Issues | Wiki, Custom Work Items | github-audit-trail.md, azdo-audit-trail.md |
50
51---
52
53## Platform Selection Criteria
54
55### When to Use GitHub
56
57**Best for**:
58- Open source projects (public repositories)
59- Developer-centric workflows (PRs, code review focus)
60- Lightweight process (startups, small teams)
61- Git-native workflows (GitFlow, GitHub Flow, trunk-based)
62- Strong Actions ecosystem for automation
63- Integration with third-party dev tools
64
65**Strengths**:
66- ✅ Excellent developer experience
67- ✅ Free for public repositories
68- ✅ Strong community and marketplace
69- ✅ Simple, intuitive UI
70- ✅ Best-in-class code review
71- ✅ Actions for flexible automation
72
73**Limitations**:
74- ❌ Limited work item hierarchy (no built-in epic → feature → story)
75- ❌ Basic project management features
76- ❌ Limited reporting/analytics (compared to Azure DevOps)
77- ❌ No built-in test management
78- ❌ Weaker audit logging (for compliance)
79
80**CMMI Maturity**:
81- **Level 2**: Fully capable
82- **Level 3**: Fully capable with third-party tools
83- **Level 4**: Limited (external analytics tools needed)
84
85### When to Use Azure DevOps
86
87**Best for**:
88- Enterprise projects (regulated industries)
89- Complex work item hierarchies (epic → feature → story)
90- Integrated ALM (requirements → design → test → deploy)
91- Advanced reporting and analytics
92- Compliance and audit requirements
93- Microsoft stack integration (.NET, Azure)
94
95**Strengths**:
96- ✅ Rich work item management
97- ✅ Built-in test management
98- ✅ Advanced analytics and reporting
99- ✅ Audit logging for compliance
100- ✅ Integrated CI/CD with environments
101- ✅ Customizable processes
102
103**Limitations**:
104- ❌ Steeper learning curve
105- ❌ More complex to configure
106- ❌ Less developer-friendly UX
107- ❌ Weaker community/marketplace
108- ❌ Limited free tier
109
110**CMMI Maturity**:
111- **Level 2**: Fully capable
112- **Level 3**: Fully capable (native features)
113- **Level 4**: Fully capable (native analytics, baselines)
114
115### Hybrid Scenarios
116
117**Common patterns**:
118- **GitHub + Azure DevOps Boards**: Code in GitHub, work tracking in Azure DevOps
119- **Azure DevOps + GitHub Actions**: Work items in Azure DevOps, CI/CD in GitHub
120- **Multi-Platform**: Microservices split across platforms
121
122**Integration options**:
123- Azure Boards + GitHub integration (official)
124- Zapier/Make for workflow automation
125- API-based synchronization
126- Third-party tools (Unito, Workato)
127
128---
129
130## Reference Sheets
131
132The following reference sheets provide detailed, production-ready implementation guidance for each platform.
133
134### GitHub Integration (5 Sheets)
135
136#### 1. Requirements Management in GitHub
137
138**When to use**: Implementing REQM (Requirements Management) in GitHub
139
140→ See [github-requirements.md](./github-requirements.md)
141
142**Covers**:
143- Issue templates for requirements with traceability IDs
144- Label strategy for requirement types and states
145- Projects/Milestones for requirement organization
146- PR linking patterns (`Implements #123`, `Closes #456`)
147- Traceability matrix automation
148- Requirement change management workflow
149- Level 2/3/4 scaling requirements
150- Audit trail for requirements changes
151
152#### 2. Configuration Management in GitHub
153
154**When to use**: Implementing CM (Configuration Management) in GitHub
155
156→ See [github-config-mgmt.md](./github-config-mgmt.md)
157
158**Covers**:
159- Branch protection rules (required reviewers, status checks)
160- CODEOWNERS file format and enforcement
161- Git workflow comparison (GitFlow, GitHub Flow, trunk-based)
162- Merge strategies (squash, merge, rebase) trade-offs
163- Baseline management (tags, releases)
164- Release management automation
165- Emergency hotfix procedures
166- Configuration as code (settings.yml, Terraform)
167
168#### 3. Quality Gates in GitHub
169
170**When to use**: Implementing VER, VAL, PI (Verification, Validation, Integration) in GitHub
171
172→ See [github-quality-gates.md](./github-quality-gates.md)
173
174**Covers**:
175- GitHub Actions workflows for CI/CD
176- Multi-stage pipelines (build → test → deploy)
177- Required status checks configuration
178- Test execution and coverage enforcement
179- Deployment environments and protection rules
180- Approval workflows for production
181- Quality metrics collection
182- Integration testing strategies
183
184#### 4. Measurement in GitHub
185
186**When to use**: Implementing MA (Measurement & Analysis) in GitHub
187
188→ See [github-measurement.md](./github-measurement.md)
189
190**Covers**:
191- GitHub Insights and API for metrics
192- DORA metrics implementation (all 4 metrics)
193- Metrics collection automation (Actions)
194- Dashboard creation (external tools integration)
195- Historical baseline tracking
196- Statistical process control (Level 4)
197- Alerting on metric thresholds
198- Custom metrics for project needs
199
200#### 5. Audit Trail in GitHub
201
202**When to use**: Compliance and audit requirements in GitHub
203
204→ See [github-audit-trail.md](./github-audit-trail.md)
205
206**Covers**:
207- Commit history as audit log
208- PR review history retention
209- Issue comment trails
210- Action logs and artifact retention
211- Compliance mappings (SOC 2, ISO, GDPR)
212- Audit report generation
213- Data retention policies
214- Access control for sensitive data
215
216### Azure DevOps Integration (5 Sheets)
217
218#### 6. Requirements Management in Azure DevOps
219
220**When to use**: Implementing REQM (Requirements Management) in Azure DevOps
221
222→ See [azdo-requirements.md](./azdo-requirements.md)
223
224**Covers**:
225- Work item types (Epic, Feature, User Story, Requirement)
226- Custom fields for traceability
227- Backlogs and boards configuration
228- Queries for requirement reporting
229- Multi-level hierarchy management
230- Change request workflow
231- Requirement baseline management
232- Integration with test plans
233
234#### 7. Configuration Management in Azure DevOps
235
236**When to use**: Implementing CM (Configuration Management) in Azure DevOps
237
238→ See [azdo-config-mgmt.md](./azdo-config-mgmt.md)
239
240**Covers**:
241- Azure Repos branch policies
242- Required reviewers and CODEOWNERS
243- Linked work items enforcement
244- Merge strategies and build validation
245- Release management with environments
246- Baseline tagging automation
247- TFVC migration (if needed)
248- Configuration as code (YAML pipelines)
249
250#### 8. Quality Gates in Azure DevOps
251
252**When to use**: Implementing VER, VAL, PI (Verification, Validation, Integration) in Azure DevOps
253
254→ See [azdo-quality-gates.md](./azdo-quality-gates.md)
255
256**Covers**:
257- Azure Pipelines multi-stage YAML
258- Quality gates between stages
259- Test Plans integration
260- Approval workflows and gates
261- Deployment environments
262- Release management strategies
263- Test execution and reporting
264- Quality metrics tracking
265
266#### 9. Measurement in Azure DevOps
267
268**When to use**: Implementing MA (Measurement & Analysis) in Azure DevOps
269
270→ See [azdo-measurement.md](./azdo-measurement.md)
271
272**Covers**:
273- Analytics views and widgets
274- Dashboard creation and customization
275- OData queries for custom reports
276- PowerBI integration
277- DORA metrics implementation
278- Process baselines (Level 3/4)
279- Historical data analysis
280- Statistical process control
281
282#### 10. Audit Trail in Azure DevOps
283
284**When to use**: Compliance and audit requirements in Azure DevOps
285
286→ See [azdo-audit-trail.md](./azdo-audit-trail.md)
287
288**Covers**:
289- Work item history and revisions
290- Audit logs (admin actions, permission changes)
291- Pipeline run history retention
292- Compliance features (data residency, encryption)
293- Audit report generation
294- Retention policies configuration
295- Access control and permissions
296- Regulatory compliance (FDA, ISO, SOC 2)
297
298---
299
300## Common Mistakes
301
302| Mistake | Why It Fails | Better Approach |
303|---------|--------------|-----------------|
304| **Treating platform as CMMI-aware** | Platforms don't enforce CMMI; you configure enforcement | Map each CMMI practice to platform feature explicitly |
305| **Using platform defaults** | Defaults are permissive (no quality gates, no reviews) | Configure branch protection, required checks, policies |
306| **Manual traceability** | Spreadsheet traceability becomes stale immediately | Automate with issue/PR links, work item queries, API |
307| **Skipping audit trail setup** | Compliance failures discovered during audit | Configure retention, access logs, history from project start |
308| **One-size-fits-all configuration** | Level 2 project gets Level 4 overhead (or vice versa) | Scale configuration based on CMMI target level |
309| **Forgetting baselines** | No way to freeze requirements or code for releases | Implement baseline tagging, release branches, milestone freezes |
310| **Ignoring platform limitations** | GitHub weak at test management; Azure DevOps weak at code review | Use hybrid approach or third-party tools for gaps |
311| **No verification automation** | Traceability breaks without detection | Scheduled checks for orphaned requirements, missing links |
312| **Generic metrics** | Collecting data nobody uses | GQM approach: Goal → Question → Metric (actionable only) |
313| **Missing cross-process links** | Requirements don't link to risks; tests don't link to design | Document integration patterns in configuration |
314
315---
316
317## Integration with Other Skills
318
319| When You're Doing | Also Use | For |
320|-------------------|----------|-----|
321| Platform setup for requirements | `requirements-lifecycle` | REQM/RD process definitions |
322| Platform setup for CI/CD | `design-and-build` | TS/PI process definitions |
323| Platform setup for testing | `quality-assurance` | VER/VAL process definitions |
324| Platform setup for metrics | `quantitative-management` | MA/QPM metrics definitions |
325| Platform selection decision | `governance-and-risk` | Decision analysis for platform choice |
326| Initial platform adoption | `lifecycle-adoption` | Incremental rollout strategy |
327
328---
329
330## Next Steps
331
3321. **Determine your platform**: GitHub, Azure DevOps, or hybrid
3332. **Identify CMMI process area**: Which process (REQM, CM, VER, etc.) are you implementing?
3343. **Check target maturity level**: Level 2, 3, or 4 (from CLAUDE.md or user)
3354. **Load reference sheet**: Read platform-specific implementation guide
3365. **Apply configuration**: Use production-ready examples from reference sheet
3376. **Verify setup**: Run verification checks for traceability, quality gates, audit trail
3387. **Integrate processes**: Link requirements → code → tests → metrics
339
340**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.