Checkpoint Lab — Static Analysis, Clean Code, Technical Debt, and Quality Governance

1. Checkpoint scenario and success criteria

You are onboarding a small synthetic service to a code-quality program. The organization wants a release signal, but it explicitly forbids developer ranking, real customer code/data, hidden policy changes, and “green means secure” claims. Your job is to create a charter, run one baseline, preserve the evidence chain, perform a narrow remediation, diagnose one controlled failure, and hand off an auditable packet.

Success means another engineer can answer: what exact revision was analyzed, with which product/scanner baseline, under which quality standard/New Code/gate, what server task produced the result, what changed after remediation, and what limitations remain?

2. Preflight: stop if the environment is not disposable

3. Write the quality-governance charter

Create evidence/QUALITY_CHARTER.md with this structure:

# Chapter 01 Quality Charter

## Scope
- Project key: devops-academy-sonarqube-ch01
- Source: synthetic training repository only
- Revision rule: every result must record an immutable Git SHA

## Quality standard
- Product/mode: record Community Build version and Standard Experience or MQR Mode
- Quality profile: record effective profile per language
- New Code definition: record current value and rationale
- Quality gate: record gate name, status, and failed conditions

## Decisions and ownership
- Code findings: project maintainer
- Security hotspot review: designated reviewer
- Policy changes: quality-program owner
- Exceptions: scope + rationale + approver + expiry/review date

## Prohibited uses
- No developer ranking by issue/debt counts
- No claim that a green gate proves functional correctness or complete security
- No threshold/rule/baseline change solely to make the current run green

## Evidence retention
- Revision, versions, non-secret parameters, scanner log,
  report task ID/status, project result, gate, interpretation, limitations

4. Start the pinned lab and establish source identity

Reuse the synthetic sq-ch01-quality-lab repository from Lesson 2 or recreate it. Confirm the worktree is clean and record the exact revision:

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

docker pull sonarqube:26.9.0.129388-community
docker image inspect sonarqube:26.9.0.129388-community \
  --format '{{.Id}}' | tee evidence/checkpoint-server-image-id.txt

docker run -d --name sq-ch01-server \
  -p 127.0.0.1:9000:9000 \
  sonarqube:26.9.0.129388-community

Complete local project/token setup exactly as in Lesson 2. Do not paste the token into the charter or screenshots.

5. Create a non-secret run manifest

Record assumptions before scanning. A plain-text or JSON manifest is appropriate:

{
  "run_id": "ch01-baseline-001",
  "date": "2026-09-07",
  "project_key": "devops-academy-sonarqube-ch01",
  "source_revision": "REPLACE_WITH_GIT_SHA",
  "server": "Community Build 26.9.0.129388",
  "server_image": "sonarqube:26.9.0.129388-community",
  "scanner": "record sonar-scanner -v output",
  "mode": "record observed Standard Experience or MQR Mode",
  "quality_profile": "record observed profile",
  "new_code_definition": "record observed value",
  "quality_gate": "record observed gate",
  "secrets_in_packet": false
}

Do not invent unknown values. Replace each “record observed” field only after independent inspection.

6. Predict at least four state changes

1. Source: baseline scan should correlate to the current Git SHA; remediation will create a different SHA.
2. Scanner/report: each successful run should create its own scanner evidence and report-task identity.
3. Server/project: each processed report should produce a new analysis result; findings/measures may change after remediation.
4. Policy: profile, mode, New Code definition, and gate should stay unchanged unless you intentionally govern a policy change.

Write these predictions into evidence/PREDICTIONS.md before execution. The checkpoint is failed if you rewrite the prediction after seeing the result.

7. Run the baseline and correlate every layer

sonar-scanner -v | tee evidence/checkpoint-scanner-version.txt
sonar-scanner 2>&1 | tee evidence/checkpoint-baseline-scanner.log
cp .scannerwork/report-task.txt evidence/checkpoint-baseline-report-task.txt

Using the task identity, wait for the corresponding background task to complete. Then record the project analysis/revision identity, active profile, mode, New Code definition, issue/measure summary, quality-gate name/status, and any failed conditions. Screenshots are optional; structured/text evidence is easier to review and diff. Redact internal URLs or identifiers if the packet ever leaves the lab.

8. Write “proves / does not prove” before remediation

9. Make one source remediation without changing policy

Fix one clearly justified issue or code-review defect in src/pricing.js. Do not touch gate thresholds, active rules, mode, or New Code baseline. Commit and record the new revision:

git add src/pricing.js
git commit -m "ch01-checkpoint: remediate baseline defect"
git rev-parse HEAD | tee evidence/checkpoint-remediated-revision.txt
sonar-scanner 2>&1 | tee evidence/checkpoint-remediated-scanner.log
cp .scannerwork/report-task.txt evidence/checkpoint-remediated-report-task.txt

After processing, verify your predictions: the revision and task changed; relevant finding/measure state may change; the policy objects should remain stable. If they do not, investigate rather than editing the evidence note to match your expectation.

10. Failure drill: break one layer, preserve it, repair only that layer

Choose one reversible failure:

• temporarily remove SONAR_TOKEN from the shell; or
• temporarily set SONAR_HOST_URL to the unused loopback port http://127.0.0.1:9001.

Run one scan and save the first failure log as evidence/checkpoint-deliberate-failure.log. Classify the failed layer before restoring the correct secret/URL. Verify that restoring the exact input returns the smallest equivalent scenario to the prior behavior.

11. Assemble the evidence packet

The packet should contain enough evidence to audit the chapter while containing no credential:

evidence/
├── QUALITY_CHARTER.md
├── PREDICTIONS.md
├── LIMITATIONS.md
├── checkpoint-run-manifest.json
├── checkpoint-source-revision.txt
├── checkpoint-remediated-revision.txt
├── checkpoint-server-image-id.txt
├── checkpoint-scanner-version.txt
├── checkpoint-baseline-scanner.log
├── checkpoint-baseline-report-task.txt
├── checkpoint-remediated-scanner.log
├── checkpoint-remediated-report-task.txt
├── checkpoint-deliberate-failure.log
└── server-final.log

Before sharing it, search for the token value, authorization headers, private URLs, personal paths, and proprietary source. Evidence quality includes privacy discipline.

12. Verification checklist

• The exact baseline and remediation Git SHAs are recorded.
• The server image/tag and scanner/runtime identities are recorded.
• The token is absent from Git, properties, commands, logs, screenshots, and the packet.
• Each successful scanner run has corresponding report-task evidence.
• Each report task is correlated to a terminal server result before gate interpretation.
• Profile, mode, New Code, gate, findings/measures, owner, and exceptions are recorded.
• At least two predictions were compared with independent observations.
• The deliberate failure was diagnosed by layer and fixed with a narrow rollback.
• LIMITATIONS.md states that static analysis/gate success is not proof of correctness or complete security.
• No policy was weakened solely to pass the checkpoint.

13. Cleanup and rollback

docker logs sq-ch01-server > evidence/server-final.log 2>&1
unset SONAR_TOKEN SONAR_HOST_URL
docker stop sq-ch01-server
docker rm sq-ch01-server

If you delete the project in SonarQube, verify the exact training project key first. Preserve the sanitized evidence packet before deletion. Do not reuse this cleanup against a shared server or broad Docker resources.

14. Chapter 01 handoff

You now have the minimum viable operating model for governed static analysis: immutable source identity, explicit analysis inputs, asynchronous task evidence, project findings/measures, a New Code context, a gate decision, human ownership, and a limitations statement. That foundation prevents later architecture, scanner, CI, security, and administration features from becoming disconnected settings.

Knowledge check

Official references and version notes

• SonarQube downloads — release identities for Community Build and SonarQube Server.
• SonarQube Community Build documentation — current self-managed Community Build product documentation.
• Changing modes — Standard Experience versus Multi-Quality Rule (MQR) Mode semantics.
• Quality gate introduction — gate purpose and policy model.
• About new code — Clean-as-You-Code and new-code definition choices.
• Metric definitions — maintainability, remediation effort, debt ratio, and rating definitions.
• Rules — rules, issue generation, and mode-dependent classification.
• SonarScanner CLI — scanner execution guidance.
• SonarSource scanner update-center metadata — scanner release metadata used to pin the lab launcher.
• Official SonarQube Docker tags — container tag provenance for the disposable lab.