Checkpoint Lab — Portfolios, Applications, Enterprise Reporting, and Governance Boundaries

1. Checkpoint scenario

You own governance for a synthetic “Digital Commerce” domain with three projects: payments, orders, and web. Payments and orders share one release train; web releases independently. Your task is to build a free Community Build governance dossier and describe exactly how the same topology would map to a Developer Application and Enterprise Portfolio/PDF if licensed.

The checkpoint succeeds only when an executive signal can be followed back to project-level revision, ceTaskId, analysis date, measures, and Quality Gate.

2. Exact assumptions and preflight

export SONAR_HOST_URL="http://localhost:9000"
sonar-scanner --version
curl -fsS "$SONAR_HOST_URL/api/system/status"
git rev-parse HEAD

3. Write predictions before action

Record at least these predictions:

• Prediction A: each scanner run will create a different ceTaskId tied to the same Git SHA but to its own project key and report input.
• Prediction B: the governance report will not mutate project measures or Quality Gates; it is read-only derived evidence.
• Prediction C: a portfolio-style A, if produced, will not imply every project gate is OK; every member row will remain visible.
• Prediction D: Application/Portfolio/PDF capabilities will remain absent from the mandatory Community Build workflow and will be labeled simulated.

4. Produce project evidence

Use the three-project fixture from Lesson 2 or recreate it exactly. For each project:

1. Generate coverage before scanning.
2. Run SonarScanner with the project’s own project-analysis token.
3. Copy .scannerwork/report-task.txt.
4. Extract ceTaskId and poll /api/ce/task to terminal state.
5. Record the project key, Git SHA, scanner version/runtime, coverage report checksum, analysis date, measures, and Quality Gate.

sha256sum payments/coverage.xml orders/coverage.xml web/coverage.xml \
  | tee evidence/coverage-checksums.txt

git rev-parse HEAD | tee evidence/source-revision.txt

5. Freeze the governance definition before reporting

{
  "definition_version": 1,
  "effective_utc": "2026-09-08T00:00:00Z",
  "application_simulation": {
    "name": "Checkout",
    "members": ["sq-ch25-payments", "sq-ch25-orders"],
    "branch_assumption": "main",
    "edition_boundary": "native Application requires Developer Edition+"
  },
  "portfolio_simulation": {
    "name": "Digital Commerce",
    "members": ["sq-ch25-payments", "sq-ch25-orders", "sq-ch25-web"],
    "branch_assumption": "main",
    "edition_boundary": "native Portfolio requires Enterprise Edition+"
  },
  "pdf_boundary": "native PDF reporting requires Enterprise Edition+"
}

Hash and retain this manifest. A later membership edit creates definition version 2; it must not silently rewrite the historical report population.

6. Generate the governance report twice

python governance_report.py
cp governance-report.json evidence/report-run-1.json
cp governance-report.md evidence/report-run-1.md
sleep 1
python governance_report.py
cp governance-report.json evidence/report-run-2.json
cp governance-report.md evidence/report-run-2.md

Project data should remain materially identical between runs because the script is read-only; only the report-generation timestamp should change unless a project was independently reanalyzed. This proves the reporting layer does not own project state.

7. Verify aggregation independently

Quality Gate/releasability

Count each visible project’s alert_status. Recompute pass ratio manually and apply the documented A/B/C/D/E bands. Confirm the report’s grade.

Ratings

For each available rating family, record the metric key used (MQR or Standard Experience). Convert numeric 1–5 values to letters and independently recompute the arithmetic mean/half-up rounding used by the portfolio-style simulation.

Coverage

Do not use the displayed project coverage percentages. Sum covered lines/conditions and total lines/conditions from raw measures, then recompute the documented formula. If any required raw count is absent, the correct report behavior is N/A, not a guessed percentage.

8. Freshness and stale-data guard

Add a checkpoint policy: flag any member whose latest analysis date exceeds a chosen lab threshold (for example, seven days). The threshold is a governance policy, not a Sonar metric.

freshness_policy:
  source: project analysis date
  warning_after: 7 days
  report_generation_time_is_not_analysis_time: true
  stale_member_action: preserve row + flag owner; do not drop from membership

9. Edition-aware native plan

10. Required evidence packet

11. Guarded cleanup and rollback

• Revoke the three project-analysis tokens and reporting User token; verify revoked credentials fail.
• Delete only the three disposable sample projects after the evidence packet is complete, if you created them solely for this checkpoint.
• On a licensed sandbox, delete only the Application/Portfolio created for the lab after exporting definition/recalculation evidence.
• Do not delete unrelated projects, global Quality Gates, profiles, database/search data, or PDF/report settings.
• Keep the evidence packet and definition history after cleanup.

12. What Chapter 25 adds to the operating model

The operating model now spans from source revision and scanner evidence through project policy into organization-level governance. It treats Applications and Portfolios as derived, edition-aware views; makes aggregation formulas explicit; preserves freshness and authorization boundaries; and requires every executive signal to drill back to an owning project.

Chapter 26 moves from governance views to the executable extension boundary: Marketplace, Plugins, Extension Risks, and Compatibility Management. There, the same evidence discipline will be applied to third-party code that can affect server availability and upgrade safety.

Knowledge check

Official references and version notes

• SonarQube downloads and editions — current Community Build, commercial release stream, Developer/Enterprise/Data Center feature boundaries, and current LTA.
• SonarQube Server — Applications — lifecycle-oriented synthetic aggregation, consolidated application view/gate, and recalculation model.
• Managing applications — creation/admin permissions, project/branch membership, and background recalculation.
• SonarQube Server — Portfolios — Enterprise boundary, releasability, rating conversion/averaging, breakdown, trend, and last-analysis context.
• Managing portfolios — permissions, project/branch selection, applications/nested portfolios, and recalculation.
• PDF reports — Enterprise Edition+ reports for projects/applications/portfolios, subscriptions, and permanent-branch constraints.
• Measures and metrics — coverage numerator/denominator, ratings, Quality Gate metrics, and portfolio-visible metric boundaries.
• Community Build Web API — bearer authentication and documented project evidence retrieval used by the free lab.