Release checks
Check identity, connection, messaging, offline recovery, security, capacity, and rollback before release.
Connecting and sending one message proves only the basic path. Before production, exercise failure cases with your real clients, server configuration, and application APIs.
Freeze the release inputs
Record and review:
- exact client SDK versions and lockfiles;
- the WuKongIM server version and configuration;
- supported client systems, devices, and networks;
- versions of login, token, channel metadata, conversation, history, and media APIs;
- database or protocol changes and their rollback path.
Release and roll back dependencies, configuration, and lockfiles as one change unit.
Minimum messaging loop
Use two real test accounts, Alice and Bob, in independent clients:
- Log in and reach the send-ready state on both clients.
- Alice sends text to Bob and shows that the server accepted it.
- Bob receives the online message exactly once.
- Bob loses network access and Alice sends another message.
- Bob reconnects, restores the missed message, and shows correct order and unread state.
- Both users log out and back in without local data crossing accounts.
The sender's server result, the recipient's live message, and offline synchronization are three separate events. Check each one independently.
Release checklist
| Area | Verify at minimum |
|---|---|
| Identity | Invalid, expired, revoked, and wrong-UID tokens are rejected; clients hold no Product HTTP administrative credentials |
| Connection | Weak networks, network changes, foreground/background, server restart, kick-out, and token expiry produce clear UI state |
| Messages | Sending, success, failure, retry, duplicates, ordering, and timeout cannot create incorrect product state |
| Conversations | Last message, unread count, deletion, and multi-device changes converge |
| Media | Upload failure, cancellation, timeout, URL authorization, and local-file cleanup meet product requirements |
| Local data | Account isolation, backup, encryption, logout cleanup, and upgrade migration meet security requirements |
| Network security | Client entry uses controlled TLS/WSS; Product HTTP, Manager, and diagnostics are not publicly exposed |
| Capacity | Load tests cover target online users, message rate, and group size with bounded queues, retries, and degradation |
| Observability | Metrics and redacted logs can locate connection, send, delivery, sync, and storage failures |
| Rollback | Client and server rollback is rehearsed in staging, and older versions can still read existing data |
Go / No-Go
Stop the release when any of these is true:
- identity verification or network boundaries are incomplete;
- a critical failure case cannot be reproduced and recovered reliably;
- logs expose tokens or complete message payloads;
- capacity misses the target or has no explicit rate-limit and degradation policy;
- a data change cannot roll back and has no reviewed forward-repair plan.
After all checks pass, begin with a small rollout. Observe connection success, send failures, message latency, sync errors, queue levels, and storage errors before expanding traffic.
Continue with Authentication & Security, the Production Checklist, Health & Monitoring, and Upgrade & Migration.