Chapter 02Lesson 05~145 minutes

Checkpoint Lab — SonarQube Product Model, Editions, Components, and Architecture

Produce an edition-aware architecture dossier that traces one synthetic analysis from source revision to scanner, task, persistent result, gate, developer feedback, and enterprise/cloud decision boundaries.

CheckpointArchitecture dossierEvidence packetEdition-awareRecovery drill

Learning objectives — Checkpoint outcomes

Prove every owner in one SonarQube analysis chain.
Run a local Community Build baseline with exact version/revision/parameter evidence.
Correlate report metadata to CE task and durable project/gate state.
Document Developer/Enterprise/DCE/Cloud/IDE boundaries without paid requirements.
Diagnose one safe deliberate mismatch and preserve the first failure.

1. Scenario

Create an internal architecture dossier for a disposable project sq-arch-checkpoint. The executable environment is local Community Build with synthetic source. The dossier must answer: what revision was analyzed; by which scanner/runtime; against which product/version; what server task processed it; what durable project/policy result exists; and which component/product would own future enterprise, DCE, Cloud, or IDE capabilities.

2. Preflight and abort criteria

Endpoint is loopback/private disposable infrastructure.
Repository is synthetic and contains no PII/secrets/proprietary code.
Community Build version and package/image are recorded.
Scanner/runtime identity is recorded from actual execution.
Token is least-privilege, fake/rotatable, and never stored in artifacts.
Project key is unique to the lab.

Abort: if the key belongs to a real/shared project, the credential is an irreplaceable admin token, or source/endpoint ownership is unclear.

3. Predictions before mutation

The scanner will create local analysis/report metadata and a task identity without changing the Git SHA.
Only after successful CE processing will durable project analysis/gate state update.
IDE-only analysis does not create a server CE task by itself.
A commercial capability cannot be enabled in Community Build with an undocumented scanner property.

Choose at least two predictions and verify them independently.

4. Execute and capture the chain

Record git rev-parse HEAD and worktree status.
Record product/version/edition, endpoint, scanner/runtime, and plugin/integration inventory.
Run the smallest current scanner with minimal project configuration.
Capture indexed-file/report-upload evidence and task metadata.
Preserve ceTaskId or the current equivalent identifier.
Wait for CE terminal status.
Record project revision/timestamp, issues/measures, active profile, New Code definition, and gate result.

SHA → scanner/runtime → effective parameters → report/upload →
              task ID → CE status → durable analysis → policy/gate →
              external/IDE interpretation

5. Required dossier sections

Section	Minimum content	Pass condition
Product identity	Community/Server/Cloud/IDE, version, edition	No “latest” ambiguity
Client	scanner family/version, JRE/runtime	Actual output recorded
Source	repo, SHA, worktree status	Exact revision reproducible
Task lifecycle	report evidence, task ID, CE status	Client/server states separated
Policy/result	analysis, profile, New Code, gate	Correlated to revision/task
Infrastructure	single-node DB/search ownership model	No direct DB/search edits
Edition map	Developer/Enterprise/DCE/Cloud/IDE implications	Commercial items simulated/optional
Security	token scope/redaction/data classification	No secret/source leakage
Limitations	what lab proves/does not prove	No HA/capacity/commercial claims from Community run

6. Edition-aware architecture exercise

Map these hypothetical requirements to the product/edition to evaluate, then cite the current matrix in your dossier:

Required commercial analyzer/PR capability → typically Developer or above, depending on current matrix.
Enterprise portfolios/reporting/governance → evaluate Enterprise.
Node-failure tolerance/horizontal scale → evaluate Data Center.
Reduce platform-infrastructure operations → evaluate SonarQube Cloud.

Do not purchase or enable commercial capability for mandatory completion; this is a decision simulation.

7. Safe failure drill

Create one reversible configuration/permission mismatch against the disposable lab—for example a project key for which the lab token lacks create/analyze permission. Do not use a production URL, disable TLS, or mutate database/search state.

Predict where the chain should fail.
Run once; preserve the first error/status.
Determine whether a server task was created.
Correct only the mismatched configuration/permission.
Rerun the same source/input and preserve the successful task/result separately.

8. Developer-feedback boundary

If SonarQube for IDE is installed, record one local finding/configuration state and whether connected mode is used. Explicitly note that this does not itself prove a server analysis. If the IDE is unavailable, include a faithful diagram and label the exercise simulated.

9. Verification checklist

SHA, scanner log, task ID, and server result correlate.
CE task reaches a terminal state and is preserved.
Gate evidence appears after server processing, not merely upload.
No token, Authorization header, PII, or proprietary path is saved.
Database/search were observed only through supported evidence.
All commercial capabilities are labeled edition-dependent and optional/simulated.
Cloud and IDE are distinguished from deployable Server editions.
The deliberate first failure remains in the packet after repair.

10. Cleanup and rollback

Archive only redacted evidence.
Remove scanner work/cache only after preserving required metadata.
Delete only the disposable project through supported UI/API if desired.
Revoke/delete the lab token.
Stop/remove only lab containers/volumes and synthetic files you created.

11. What this proves—and does not prove

The checkpoint proves that you can identify product/component ownership, correlate client and server states, reason about edition boundaries, and preserve diagnostic evidence. It does not prove Data Center failover, production capacity, enterprise identity, backup/restore, commercial security engines, or Cloud migration correctness; those belong to later chapters and authorized environments.

Knowledge check

Best identifier for joining upload evidence to server processing?

Analysis exists and gate is red. Is scanner broken?

Can this Community lab prove DCE HA?

Why keep the first-failure log after repair?

Core chapter invariant?

Next lesson — Next chapter

From architecture to supported installation

Chapter 03 turns this model into installation prerequisites, database planning, runtime compatibility, and a reproducible first server.

Official references and version notes

SonarQube downloads and edition comparison — current Community Build, Developer, Enterprise, Data Center, and LTA identities.
Community Build documentation — free self-managed baseline.
SonarQube Server documentation — commercial Server behavior, operations, analysis, and integrations.
SonarQube for IDE documentation — local analysis and connected mode.
SonarQube Cloud documentation — hosted-product boundary.
Release announcements — dated release cross-checks.

Version and edition note

Rechecked 2026-09-07. The mandatory lab path uses Community Build 26.9.0.129388. SonarQube Server Developer, Enterprise, and Data Center editions are on 2026 Release 4.1, while 2026.1.5 is the active LTA patch line. Scanner/JRE provisioning, language support, APIs, plugins, and edition capabilities evolve independently; re-check current primary documentation before applying this snapshot.

Version and compatibility note

SonarQube product names, editions, release trains, scanner runtimes, APIs, authentication options, and platform prerequisites can change independently. Re-check the linked SonarSource primary documentation for the exact target release before applying version-sensitive commands or operational guidance outside the disposable course environment.

Keep the academy open

Support free, practical DevOps education.

Every lesson is designed to remain readable in a browser, downloadable from GitHub, and usable without a paid learning platform. Contributions help expand and maintain the curriculum.

Ethereum / ERC-20

0x716c4Ab160C4B66F31a28AE2448BfF68fc3a2ef0Send only Ethereum/ERC-20 compatible assets to this address.