Section 3 of 3 · 7 minutes
Verify the release and hand it over
Your goal
What you will be able to do
Compare post-change service, database, and application signals with the baseline and give operations a clear follow-up record.
Why this matters at work
The practical reason
A release is not complete when commands finish; it is complete when the intended outcome is stable and owned.
Learn
The idea in plain English
Run the written success checks for application behaviour, query results, latency, errors, locks, replication, storage, and backups. Watch them for the agreed observation window.
The handover records the change, version, evidence, deviations, remaining risk, rollback status, dashboards, and named owners for later checks. Share only the information operators need; keep secrets out of the record.
Remember these points
- Compare the same signals measured before the change.
- Observe long enough to cover important workload cycles.
- Record remaining risk and a named follow-up owner.
See it in SQL
Record server and schema versions after release
Create a small version record for the handover.
SELECT
current_setting('server_version') AS server_version,
current_database() AS database_name,
max(version) AS latest_schema_version,
clock_timestamp() AS verified_at
FROM training_schema_migrations;The schema version proves what the application expects to find. The timestamp anchors later monitoring checks.
Add the real user-path and health checks; version agreement alone does not prove a healthy release.
The PostgreSQL version, database, latest recorded schema version, and verification time.
Useful words
Important terms
- Observation window
- The agreed time after a change during which success and regression signals are actively checked.
Quick check · Not graded
Check your understanding
When is a production change complete?
Your progress is saved to your signed-in account.