Checkpoint Lab — Capstone: Operate a Governed Production SonarQube Quality Platform

1. Final checkpoint mission

Deliver a reviewable production-readiness dossier for the disposable sq34:capstone platform. The assessor should be able to reconstruct the operating model without trusting your memory: what version ran, what source was analyzed, how the report/task/result connected, which policy decided, what credential/trust boundary existed, how the database was backed up/restored, how updates/capacity are governed and which risks remain.

2. Exact assumptions and resource/credential preflight

Freeze the environment you are assessing. If your actual version differs from the baseline, do not falsify it—record the real version and rerun the compatibility checks.

3. Write predictions before actions

Predict at least two state changes. This is a capstone control: you must know which layer should change before you touch it, then verify using a different evidence source.

# evidence/governance/predictions.yaml
predictions:
  - id: P1
    before: project sq34:capstone has the currently recorded gate assignment
    action: run a new analysis of the exact recorded revision with coverage.xml present
    expected_change: a new CE task/analysis record is created; source revision/project key stay unchanged
    independent_verification:
      - scanner report-task.txt
      - CE task status/API or UI
      - project analysis timestamp/result
  - id: P2
    before: backup artifact exists but restore target does not
    action: restore database to isolated sq34restore stack with fresh search/data volume
    expected_change: isolated server reconstructs project/config from restored durable state and builds usable indexes
    independent_verification:
      - restore logs + system status
      - project/config inspection
      - fresh equivalent analysis task
  - id: P3
    before: fake bounded exception SQ34-EX-001 is active in external governance ledger
    action: reach its review/expiry decision
    expected_change: exception closes or is explicitly renewed with new evidence; Sonar technical result is not silently suppressed
    independent_verification:
      - governance ledger diff
      - unchanged issue/gate evidence unless separately remediated

4. Required production-readiness evidence packet

Use a stable packet structure so review is mechanical instead of anecdotal.

evidence/
├── 00-generated-at.txt
├── 00-revision.txt
├── 00-sonarqube-image.txt
├── 00-database.txt
├── 00-scanner-version.txt
├── architecture/
│   ├── platform.mmd
│   ├── trust-boundaries.md
│   └── edition-matrix.md
├── scanner/
│   ├── effective-inputs.md
│   ├── analysis.log
│   └── report-task.txt
├── server/
│   ├── startup.log
│   ├── ce-task.json
│   ├── health.json
│   └── plugin-inventory.txt
├── policy/
│   ├── profile.md
│   ├── quality-gate.json
│   ├── new-code.md
│   └── exception-ledger.yaml
├── api/
│   ├── api-contract.md
│   ├── measures.json
│   └── permission-check.md
├── ci/
│   ├── producer.log
│   ├── pipeline-evidence.md
│   └── ide-or-provider-simulation.md
├── backup/
│   ├── sonarqube.dump
│   ├── sonarqube.dump.sha256
│   ├── restore.log
│   └── restore-verification.md
├── operations/
│   ├── upgrade-plan.md
│   ├── compatibility-matrix.md
│   ├── capacity-baseline.csv
│   └── incident-SQ34-INC-001.yaml
└── governance/
    ├── owners.md
    ├── predictions.yaml
    ├── review-decision.md
    ├── residual-risks.yaml
    └── assumptions-limitations.md

5. Execute the production-readiness review cycle

The checkpoint is intentionally broad, but each step is small. Reuse the runnable commands from Lessons 2 and 4 rather than inventing a second, inconsistent platform.

1. Architecture/version inventory: capture container image digests, database/scanner/JRE mode, deployment topology, ports, persistence paths and trust boundaries.
2. Build/test: run the synthetic tests and coverage producer; preserve producer log and reports before analysis.
3. Analysis: run scanner with stable project key and revision; preserve effective inputs, indexing/import log and report-task.txt.
4. Compute/result: verify referenced CE task, then capture current measures/issues/analysis identity.
5. Policy: capture active profile, gate conditions/status and New Code definition; document any bounded exception separately.
6. Security/RBAC: prove token ownership/purpose and a permission outcome without recording secret value; verify TLS/trust assumptions for any non-local adaptation.
7. Automation/developer feedback: save a bearer-auth API read and either a local CI/Connected Mode artifact or clearly labeled provider simulation.
8. Observability: capture health/startup/CE/search-relevant logs and the capacity baseline from an equivalent analysis.
9. Recovery: verify DB backup checksum, isolated restore, fresh index/reindex behavior and a fresh validation analysis.
10. Upgrade: write current→target compatibility/update plan including Java/database/scanner/plugin/API prerequisites and recovery boundary.
11. Incident: run the bounded auth/report-path incident or interpret the synthetic CE case, preserve first failure, apply one correction and prove same-input rerun.
12. Governance: review owners, exception expiry, adoption/remediation evidence and residual risks; sign the review decision with limitations.

6. One dossier, many independent evidence chains

The diagram is not architecture decoration. Each edge says which evidence must exist before the next conclusion is valid.

7. Production-readiness acceptance matrix

A “pass” means the minimum evidence exists and is internally consistent. Residual risk is expected; hiding it is failure.

8. Capacity evidence: enough to reason, not enough to overclaim

Record a small baseline from several equivalent local analyses. The purpose is to show the method from Chapter 31—not to extrapolate this tiny project into an enterprise sizing guarantee. Capture scanner time, CE/task time/queue wait where observable, host CPU/RAM, database/search/disk/network notes, concurrent activity and explicit headroom assumptions.

timestamp_utc,revision,loc,scanner_seconds,ce_seconds,queue_wait_seconds,host_cpu_peak_pct,host_ram_peak_mb,db_observation,disk_observation,notes
2026-09-08T00:00:00Z,<sha>,<nloc>,<measured>,<measured>,<measured>,<measured>,<measured>,<record>,<record>,bounded local synthetic run

9. Edition-aware simulation ledger

Commercial simulation is not a fake screenshot. It states the real control, the product/edition boundary and the free evidence that proves the underlying concept.

10. Residual risks and final operating decision

Production readiness is a risk decision, not a score. Name what the lab cannot prove, assign an owner and define the next evidence needed.

residual_risks:
  - id: RR-01
    risk: single-node Community Build lab does not prove high availability
    owner: platform-operations
    disposition: accepted-for-course-lab
    next_evidence: licensed DCE failure test if business availability requires it
  - id: RR-02
    risk: synthetic repository does not represent enterprise language/project mix
    owner: quality-platform-team
    disposition: requires-production-measurement
    next_evidence: 30-day workload/capacity baseline
  - id: RR-03
    risk: hosted CI/provider decoration and enterprise identity were simulated
    owner: devops-integration-team
    disposition: test-before-production
    next_evidence: provider sandbox + least-privilege integration test
  - id: RR-04
    risk: compliance/security reports do not prove secure software
    owner: security-governance
    disposition: retain-complementary-controls
    next_evidence: threat model + SCA/SBOM/DAST/runtime controls as applicable

11. Verification checklist and cleanup

• Every result is tied to the exact sq34:capstone revision and recorded effective inputs.
• At least two predicted changes were independently verified from different evidence sources.
• Scanner/upload, CE, durable analysis, gate, CI and provider/IDE states are not collapsed.
• No token/password/private key is present in the packet; fake credential metadata is clearly labeled.
• Database backup has checksum and an isolated restore/reindex/fresh-analysis verification.
• Upgrade plan records current/target compatibility and does not rely on arbitrary downgrade.
• Capacity numbers are bounded by explicit workload assumptions.
• Commercial features are optional/simulated and never required for core completion.
• Exceptions have owner/rationale/scope/expiry; metrics do not rank developers or reward exclusions.
• Residual risks name owners and next evidence instead of being hidden.

# Finalize and hash the evidence packet before cleanup.
find evidence -type f -print0 | sort -z | xargs -0 sha256sum > evidence/SHA256SUMS.txt
tar -czf ../sq34-production-readiness-evidence.tgz evidence
sha256sum ../sq34-production-readiness-evidence.tgz > ../sq34-production-readiness-evidence.tgz.sha256

# Revoke the fake/local token in the UI before destroying the lab.
unset SONAR_TOKEN SONAR_HOST_URL

# Remove only owned lab stacks after evidence archive exists.
docker compose -f compose.restore.yaml -p sq34restore down -v 2>/dev/null || true
docker compose down -v

12. Knowledge check

13. What Chapter 34 adds—and post-course production practice

Chapter 34 converts the course from a collection of SonarQube skills into an operating discipline. You can now trace a source revision through build/test evidence, scanner indexing and report upload, Compute Engine processing, persistent results, profiles/New Code/gates, CI/API/IDE/provider outcomes, operations, recovery, upgrades, capacity and governance—while keeping ownership and edition boundaries explicit.

Post-course practice should be cyclical: re-verify releases and compatibility; review permissions/tokens; sample analysis evidence; test backups/restores; inspect API deprecations; measure capacity; rehearse incidents; expire exceptions; review remediation trends and developer feedback; and update the operating model when the platform or organization changes. The durable skill is not remembering a screen. It is preserving causality and evidence as the system evolves.

Official references and version notes

Further reading

Verify version-sensitive behavior against primary documentation before using these patterns outside the disposable lab.

• SonarQube downloads — current Community Build, commercial release and LTA identities
• SonarQube Server documentation — server, administration, security and operations
• SonarQube Community Build documentation — free/local product behavior
• Web API — authentication and the ongoing Web API V2 migration
• Backup and restore — database backup/restore and reindex guidance
• Official SonarQube Docker image — current image tags and deployment notes
• LTA to LTA release notes — current Java/database/scanner compatibility changes
• Scanner environment requirements — scanner runtime and JRE auto-provisioning boundary
• Performance issues — performance troubleshooting and edition-aware CE scaling guidance