Enterprise Standards, Auditability, Developer Adoption, and Quality Programs: Guided Hands-On Workflow

1. Scenario and version assumptions

You operate two synthetic services, sq33:alpha and sq33:beta. No proprietary source, real identity provider, paid CI or enterprise license is required.

2. Create the disposable governance workspace

mkdir -p sq33-lab/projects/{alpha,beta} sq33-lab/governance sq33-lab/evidence sq33-lab/backlog
cd sq33-lab
cat > governance/standard.json <<'JSON'
{"id":"SQ-STD-2026-03","owner":"quality-program@example.invalid","requiredGate":"Sonar way","exceptionMaxDays":30,"principles":["new-code-first","no-developer-ranking","bounded-exceptions"]}
JSON
cat > governance/projects.json <<'JSON'
[{"key":"sq33:alpha","owner":"team-alpha@example.invalid","standard":"SQ-STD-2026-03"},{"key":"sq33:beta","owner":"team-beta@example.invalid","standard":"SQ-STD-2026-03"}]
JSON
echo '[]' > governance/exceptions.json

The example.invalid owners are deliberately fake. In production, use role/team identifiers appropriate to your organization.

3. Create two source revisions and stable project keys

for p in alpha beta; do
  mkdir -p "projects/$p/src"
  printf 'def normalize(v):\n    return "" if v is None else v.strip().lower()\n' > "projects/$p/src/app.py"
  printf 'sonar.projectKey=sq33:%s\nsonar.sources=src\nsonar.sourceEncoding=UTF-8\n' "$p" > "projects/$p/sonar-project.properties"
  (cd "projects/$p" && git init -q && git add . && git -c user.name='SQ33 Lab' -c user.email='sq33@example.invalid' commit -qm baseline)
done
for p in alpha beta; do (cd "projects/$p" && git rev-parse HEAD); done | tee evidence/revisions.txt

4. Run analyses and preserve asynchronous evidence

for p in alpha beta; do
  (cd "projects/$p" && sonar-scanner -Dsonar.host.url=http://localhost:9000 -Dsonar.token="$SONAR_TOKEN") 2>&1 | tee "evidence/${p}-scanner.log"
  cp "projects/$p/.scannerwork/report-task.txt" "evidence/${p}-report-task.txt"
done

Do not mark onboarding complete until each preserved task ID reaches the expected Compute Engine result. Scanner exit, upload, CE success, gate result and CI outcome are different evidence points.

5. Onboard under the shared standard

Read each project’s current quality profile(s), quality gate, New Code definition and permissions through the current UI or documented API. Record the “before” state. Apply only the changes required by SQ-STD-2026-03, then read again and record “after.” For APIs, use the target instance’s current Web API documentation because endpoint versions may evolve.

6. Deliberate drift and reconciliation

Change only Beta’s project gate assignment or New Code definition in the disposable instance. Preserve the original value and actor/rationale. The source SHA and scanner scope should remain unchanged. Drift is proven when effective project policy differs from the standard ledger. Reconciliation is proven only when a fresh policy read matches the standard and an equivalent analysis retains the frozen revision.

7. Time-bounded documented exception

[{"id":"SQ-EX-0001","projectKey":"sq33:beta","standard":"SQ-STD-2026-03","owner":"team-beta@example.invalid","approver":"quality-program@example.invalid","rationale":"training fixture: remediation depends on a planned library upgrade","created":"2026-09-08","expires":"2026-10-08","remediationIssue":"SQ33-BACKLOG-001","status":"approved-temporary"}]

The exception does not remove the issue or rewrite the analysis history. It records how delivery governance will treat the known deviation and when the decision must be revisited.

8. Review trends without ranking individuals

9. Build the audit packet and backlog

mkdir -p evidence/audit-packet
cp governance/*.json evidence/audit-packet/
cp evidence/revisions.txt evidence/audit-packet/
cp evidence/*-scanner.log evidence/audit-packet/ 2>/dev/null || true
cp evidence/*-report-task.txt evidence/audit-packet/ 2>/dev/null || true
cat > backlog/improvements.md <<'MD'
- Automate policy-drift comparison using documented APIs.
- Review exception expiry before due date.
- Publish a short profile-vs-gate-vs-New-Code onboarding lab.
- Track remediation lead time by service/risk band, never by individual.
MD

Enterprise audit logs, portfolios or PDF reports may be appended if licensed; they are not required for the core packet.

10. Challenge

Beta repeatedly drifts only in New Code because its release cadence differs. Decide whether to force the central setting, create a justified scoped variant, suppress findings, or keep granting identical exceptions. State the owning layer, required evidence and review cadence.

11. Knowledge check

12. Cleanup and rollback

Restore Beta to the approved standard, revoke only the fake lab token, remove only projects created by this lab, and preserve the audit packet. Never delete shared production policy objects as “cleanup.”

13. Summary

You have operated one shared standard. Lesson 3 turns those observations into deliberate configuration and program design choices.

Official references and version notes

• SonarQube Community Build documentation — current self-managed Community Build concepts and administration.
• SonarQube Server documentation — commercial Server administration, governance, security, and operations.
• Quality standards administration — rules, quality profiles, quality gates, and related governance controls.
• Web API — supported automation interfaces and API evolution guidance.
• SonarQube downloads — current release and edition identities.