SonarQube Product Model, Editions, Components, and Architecture: Guided Hands-On Workflow

1. Safe lab contract

Reuse the disposable Community Build pattern from Chapter 01. The target must be loopback or private lab infrastructure; source must be synthetic; credentials must be fake/rotatable and injected at runtime. Record the exact Community Build version/image/package and current scanner/runtime rather than assuming them from memory.

export SONAR_HOST_URL="http://127.0.0.1:9000"
export SONAR_PROJECT_KEY="sq-arch-lab"
# Keep SONAR_TOKEN in an interactive/temporary secret source.
# Never commit or echo it.

2. Create a revision you can prove

mkdir sq-arch-lab && cd sq-arch-lab
git init
printf 'def ratio(total, count):
    return total / count
' > app.py
git add app.py
git commit -m "lab: architecture baseline"
git rev-parse HEAD
git status --short

Record the SHA and clean/dirty status. Revision identity is part of analysis evidence, not decorative Git metadata.

3. Inventory before mutation

Use supported UI/API/system-information surfaces. Do not query or edit internal database/search state directly.

4. Run the smallest analysis

Use the current scanner documented for the sample. Record its version and JRE/runtime behavior because JRE auto-provisioning and scanner packaging evolve. Keep configuration minimal and explicit.

sonar.projectKey=sq-arch-lab
sonar.sources=.
sonar.sourceEncoding=UTF-8

Run with the token injected securely. Preserve the scanner log with secrets redacted. Capture indexed-file/report-upload evidence and the metadata written to the scanner work directory. A line that resembles “execution success” proves only the client phase.

5. Correlate to Compute Engine

Preserve the task identifier emitted in the scanner/report metadata—commonly ceTaskId in current workflows. Use the supported background-task UI or API to observe queued/in-progress/success/failed/canceled state. If the Web API endpoint changes or migrates to V2, follow the current docs and record the endpoint/version choice.

# Verify the current endpoint before automation.
curl -sS -u "$SONAR_TOKEN:"   "$SONAR_HOST_URL/api/ce/task?id=$CE_TASK_ID"

6. Inspect the durable result and policy

After CE success, record analysis revision/timestamp, issue/measure summary, active quality profile, New Code definition, and quality-gate result. The evidence chain should read:

Do not rank developers by counts and do not infer that a green gate proves runtime correctness or complete security.

7. Map the workflow to other product choices

8. Challenge: name the owner before the fix

1. Upload succeeds, project never updates: inspect the CE task.
2. Project analysis exists, PR has no decoration: inspect provider/integration state.
3. IDE and server findings differ: compare revision/scope/connected policy.
4. Expected commercial language is absent: verify current edition/language matrix.
5. Search/UI is unhealthy: preserve supported health/log/resource evidence; do not delete search data blindly.

9. Verification and cleanup

• Verify SHA, task ID, and project result correlate.
• Verify no token appears in Git/log artifacts.
• Preserve redacted first-failure evidence before cleanup.
• Delete only the disposable project through supported UI/API if needed.
• Stop/remove only lab containers/volumes and synthetic files you created.

Knowledge check

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.