Checkpoint Lab — Release Cycle, LTA Strategy, Upgrade Paths, and Migration Planning

1. Checkpoint scenario

You own a disposable Community Build 26.7 instance backed by PostgreSQL 17.11. Your goal is to rehearse the supported move to current Community Build 26.9 on a cloned database, keep the old source intact, and produce enough evidence that another operator could decide whether to proceed, stop, or restore without relying on your memory.

The checkpoint is successful only when the target's server/database migration and a fresh project analysis are independently proven. A reachable login page is not enough.

2. Exact assumptions

3. Write predictions before executing

• Prediction A: the 26.7 source project and its last successful ceTaskId remain intact because migration runs only against sq29_rehearsal.
• Prediction B: 26.9 will migrate the cloned database and become operational without requiring an intermediate installed 26.8 server.
• Prediction C: the project/history restored into the clone will be visible after target migration because that state comes from the database.
• Prediction D: a same-SHA post-update scan will produce a new target ceTaskId; scanner success and CE success will be checked separately.
• Prediction E: if acceptance fails after schema migration, rollback requires the pre-update database backup/source DB plus the 26.7 server—not 26.7 against the migrated rehearsal DB.

4. Required pre-update manifest

upgrade_id: sq29-rehearsal-20260908
source_version: 26.7.0.124771
target_version: 26.9.0.129388
release_model: Community Build calendar versioning; no LTA
supported_path: direct same-year
notes_reviewed: 26.8, 26.9
source_image_digest:
target_image_digest:
database_vendor_version: PostgreSQL 17.11
database_free_space:
backup_id:
backup_sha256:
plugins:
scanner_cli: 8.1.0.6389
api_dependencies:
ci_dependencies:
ide_dependencies:
representative_project: sq29-upgrade-lab
representative_revision:
pre_update_ceTaskId:
maintenance_window:
rollback_decision_owner:
rollback_trigger:

5. Execute the rehearsal

Use the Chapter 29 Lesson 2 Compose topology and preserve every command/output in a timestamped evidence directory. The required sequence is:

1. Start 26.7 with sq29_source; prove system status and one successful analysis.
2. Inventory version / runtime / database / plugins / scanners / APIs / CI / IDE and review 26.8/26.9 notes.
3. Measure database headroom and create pg_dump -Fc backup; calculate SHA-256.
4. Create sq29_rehearsal and restore the dump.
5. Stop source server; retain source DB and backup.
6. Start 26.9 against only sq29_rehearsal; preserve startup/migration logs and complete documented setup if requested.
7. Verify target status/project history/policy.
8. Scan the same Git SHA against 26.9 and preserve target report-task.txt, ceTaskId and CE result.
9. Run representative API/CI/IDE contract checks.
10. Compare actual evidence to predictions; accept or execute restore-based rollback plan.

6. Independent verification checklist

• ☐ Source/target images and digests are recorded.
• ☐ Source and target release/path rules are documented; Community Build is not mislabeled LTA.
• ☐ 26.8 and 26.9 release/update notes were reviewed and resulting actions recorded.
• ☐ Database version and free-space/headroom evidence are captured.
• ☐ Backup ID, size and SHA-256 are recorded; restore into a separate DB succeeded.
• ☐ Original source DB was not migrated or deleted during rehearsal.
• ☐ Target startup/migration logs are preserved from first attempt.
• ☐ Project/history and expected policy state are visible after target migration.
• ☐ Same representative Git SHA was scanned post-update.
• ☐ Post-update scanner output and report-task.txt are preserved.
• ☐ Target ceTaskId reached terminal success independently of scanner exit code.
• ☐ Gate/result and any same-SHA issue/metric changes are explained rather than hidden.
• ☐ Representative Web API/CI/IDE dependencies are validated or explicitly recorded as untested limitations.
• ☐ Rollback plan restores the pre-update DB before starting 26.7.

7. Evidence packet

8. Rollback/restore plan

IF acceptance fails after target DB migration:
1. Preserve first target failure/migration evidence.
2. Stop the 26.9 target.
3. Restore the pre-update database backup to the rollback database / retain source DB.
4. Switch deployment back to 26.7.0.124771 with its compatible config/plugins.
5. Start 26.7 only against the restored pre-update database.
6. Verify system health and a representative analysis.
7. Do not delete target evidence until root cause and next rehearsal are complete.

9. Guarded cleanup

After the lab evidence is copied to the intended location and the acceptance/rollback decision is recorded, revoke the disposable project token, stop/remove only the sq29 Compose resources, and remove the generated lab password from the shell. Do not run broad Docker prune commands and do not delete unrelated volumes.

unset SONAR_TOKEN SQ29_DB_PASSWORD
docker compose --profile source --profile target down
# Remove the lab volume only if you have explicitly accepted cleanup:
# docker volume rm sq29-upgrade-lab_sq29_pg

10. What Chapter 29 adds to the operating model

The governed SonarQube platform now has a release-control plane: every update begins with a compatibility inventory and supported path, uses a tested backup as the rollback boundary, runs on a rehearsal clone first, treats migration logs and ceTaskId as evidence, validates API/CI/IDE consumers separately, and never confuses “server started” with “platform migration accepted.”

Chapter 30 builds on this discipline for Data Center Edition, Clustering, High Availability, and Scale, where update sequencing, plugin consistency, search/application node roles, rolling availability and cluster evidence become additional concerns.

Knowledge check

Official references and version notes

• SonarQube downloads — current Community Build, commercial current release, and current LTA identities.
• Community Build — Determining the update path — direct same-year updates; December/January bridge rules across calendar years; no Community Build LTA concept.
• SonarQube Server — Release cycle model — two-month releases, yearly LTA, active-version support model, and YYYY.Release.Patch versioning.
• SonarQube Server — Determining the update path — intermediate LTA rules and update-path calculator.
• Community Build — Pre-update steps — read every intervening release note, back up the database, test first, and leave database disk headroom for migrations.
• Community Build — Performing the update — fresh installation/image, compatible plugins, configuration review, startup/migration and validation flow.
• Community Build — Post-update steps — scanner verification, database cleanup, service-path updates and API-deprecation review.
• Community Build — Other migration-related tasks — rollback requires restoring the pre-update database backup before switching back to the previous server.
• Community Build — Server host requirements — ZIP installations currently require JDK 21 or 25.
• Community Build — Database requirements — PostgreSQL 14–18 is supported in current Community Build.
• Plugin version matrix — verify every third-party plugin against the target before update.
• Deprecation policy — public APIs/features are deprecated before removal; migration planning must inventory those dependencies.
• SonarScanner CLI 8.1.0.6389 — scanner baseline used for post-update validation.
• Official SonarQube Docker tags — exact source/target image identities used by the rehearsal.