146 lines
7.2 KiB
Markdown
146 lines
7.2 KiB
Markdown
# Public launch checklist
|
|
|
|
This checklist separates properties the repository can verify from decisions
|
|
that require the operator, a provider, or jurisdiction-specific legal review.
|
|
Checking a box is an operator record, not proof created by the application.
|
|
Do not replace unknown values with estimates.
|
|
|
|
## 1. Freeze the candidate
|
|
|
|
- [ ] Record the candidate Git revision and immutable application, PostGIS,
|
|
socket-proxy, and edge image references.
|
|
- [ ] Confirm that the target is the independent production checkout, Compose
|
|
project, database, volumes, secrets, Google/Firebase project, SMTP
|
|
credentials, and Android identity.
|
|
- [ ] Keep development, hackathon test, and production credentials separate.
|
|
- [ ] Run the repository quality suite and retain its non-secret evidence.
|
|
|
|
```bash
|
|
git rev-parse HEAD
|
|
./scripts/quality.sh
|
|
```
|
|
|
|
## 2. Verify production configuration without exposing secrets
|
|
|
|
Run both checks against the single ignored production `.env`. The first reports
|
|
capabilities; the second additionally enforces the repository's release
|
|
requirements.
|
|
|
|
```bash
|
|
./scripts/validate-production-env.sh .env whoneedhelp.com
|
|
./scripts/check-environment-readiness.sh .env --require-release
|
|
```
|
|
|
|
The release check covers the application origin and secrets, database
|
|
selection, SMTP and support routing, Google OAuth, browser VAPID, Firebase/FCM,
|
|
Android package/signing configuration, and production App Links. It does not
|
|
prove that external providers will deliver successfully after deployment.
|
|
|
|
## 3. Record human and legal decisions
|
|
|
|
The following decisions are intentionally not generated by code:
|
|
|
|
- [ ] Launch jurisdictions and the exact local emergency contacts shown to
|
|
users have been approved.
|
|
- [ ] Privacy notice, Terms, medicine/prohibited-items guidance, and voluntary
|
|
payment/reimbursement wording have been reviewed for those jurisdictions.
|
|
- [ ] A retention and anonymisation schedule defines each account, safety,
|
|
dispute, moderation, support, legal, tracking-evidence, and backup record.
|
|
- [ ] The account-deletion executor and operator procedure have been approved
|
|
and tested against that schedule before destructive execution is enabled.
|
|
- [ ] Moderation, support, privacy, account-deletion, content-removal, and
|
|
incident queues have named owners and monitored contact paths.
|
|
- [ ] Provider terms and capacity are approved for email, map tiles, Google
|
|
identity, Web Push, Firebase/FCM, database hosting, backups, and monitoring.
|
|
- [ ] Google Analytics for Firebase remains disabled until the operator has
|
|
approved a purpose and event allow-list, updated the privacy notice,
|
|
implemented an explicit user analytics preference, and verified that the
|
|
Android client does not initialise Analytics before the user opts in.
|
|
Analytics events must not contain email addresses, account or device
|
|
identifiers owned by Who Need Help, request/chat/support text, medicine
|
|
details, exact or approximate coordinates, handover codes, social-account
|
|
data, or moderation and safety evidence. The initial useful event set is
|
|
limited to coarse product milestones such as `registration_completed`,
|
|
`request_created`, `helper_joined`, `handover_completed`, and
|
|
`push_opened`; every event and parameter requires a privacy review before
|
|
release. Enabling Firebase Analytics later is a separate change from the
|
|
server-side `ProductAnalytics` context, which stores only allow-listed
|
|
daily aggregate counters without user identifiers.
|
|
- [ ] Representative load measurements from the intended host and traffic shape
|
|
justify database pools, action-limit policies, replica counts, memory/CPU
|
|
allocation, alerts, and any scaling thresholds.
|
|
- [ ] Backup ownership, encryption-key custody, off-site destination, restore
|
|
procedure, and measured recovery objectives have been approved.
|
|
|
|
Until the retention decision and tested executor exist, account-deletion cases
|
|
remain an audited operator workflow and automatic erasure stays disabled. The
|
|
software must not claim that an unresolved legal or operational item is
|
|
complete.
|
|
|
|
## 4. Rehearse recovery before promotion
|
|
|
|
Create a current custom-format backup and restore it only into the isolated
|
|
drill database. Then rehearse the current release against that backup.
|
|
|
|
```bash
|
|
backup_output=$(./scripts/backup-compose.sh)
|
|
backup_path=$(printf '%s\n' "$backup_output" | sed -n 's/^Backup: //p')
|
|
./scripts/restore-drill-compose.sh "$backup_path"
|
|
./scripts/upgrade-rehearsal-compose.sh "$backup_path"
|
|
./scripts/production-rollback-drill.sh
|
|
```
|
|
|
|
Local backups and local MinIO drills verify mechanics but are not proof of
|
|
off-site durability or a production recovery policy.
|
|
|
|
The implemented external workflow can be rehearsed without restoring over the
|
|
source database:
|
|
|
|
```bash
|
|
./scripts/bootstrap-restic.sh
|
|
./scripts/production-offsite-backup.sh plan
|
|
./scripts/production-offsite-backup.sh run
|
|
systemctl --user status who-need-help-production-backup.service --no-pager
|
|
ssh buyvm-maya \
|
|
'systemctl --user status who-need-help-production-monitor.timer --no-pager'
|
|
```
|
|
|
|
Do not mark backup ownership complete merely because this command passes. The
|
|
operator must still store the Restic key independently and approve retention,
|
|
RPO, RTO, capacity, and responsible owners.
|
|
|
|
## 5. Promote with an explicit rollback point
|
|
|
|
Use the release workflow in `docs/operations.md`; do not copy mutable source
|
|
over a running production checkout. A successful release must retain the
|
|
generated rollback manifest, the pre-release backup checksum/catalog, and the
|
|
previous immutable image references. A forward-only migration must be treated
|
|
as forward-only rather than receiving an invented database rollback.
|
|
|
|
## 6. Verify the deployed product
|
|
|
|
- [x] Public HTTPS home, liveness, readiness, WebSocket upgrade, manifest, and
|
|
`assetlinks.json` return the expected production identity.
|
|
- [ ] Registration, returning-user login, and settings linking complete against
|
|
the production Google OAuth client and exact callback origin.
|
|
- [ ] A production-generated authentication email reaches an external mailbox;
|
|
sender identity and every URL use the production domain.
|
|
- [ ] Browser Web Push reaches a real subscribed browser.
|
|
- [x] The production Android build signs in, opens verified App Links, receives
|
|
FCM, and performs user-started foreground location sharing on a physical
|
|
device.
|
|
- [x] The full two-person help flow passes: create, discover, accept, chat,
|
|
optional tracking, start, handover code, both confirmations, blind review,
|
|
report/block, and notification delivery.
|
|
- [x] The Activity flow passes: create, request to join, approve/decline,
|
|
withdraw, rejoin, group chat, exact-location disclosure only after
|
|
approval, and reporting.
|
|
- [ ] Support, privacy/data, account-deletion, general content-removal, and
|
|
TAKE IT DOWN submissions reach the correct production operator queues.
|
|
- [ ] Database, application, worker, email, push, backup, and edge monitoring
|
|
are visible to the responsible operator.
|
|
|
|
Record observed timestamps, revision/image identities, and non-secret evidence
|
|
paths in `docs/verification.md`. Record failed checks as failed; do not convert
|
|
them into documentation-only success.
|