7386469404
All checks were successful
Build and deploy / Validate source (push) Successful in 5s
Build and deploy / Integration suite on a real stack (push) Successful in 1m18s
Build and deploy / Secret scan and release gate (push) Successful in 6s
Build and deploy / Publish images and notify Portainer (push) Successful in 1m26s
Thirteen files at the repository root, seven of them documents. Only README.md earns a place there; the rest are now in docs/ beside the meeting notes, the client roadmap and the historical material. The compose files stay. docker-compose.yml is the path the dtf-cloud Portainer stack reads, so moving it would break deployment, and Docker resolves a compose file's relative build contexts against its own directory, so moving the other two would silently break every build. Both reasons are now written down where someone would otherwise try it. Correcting references turned up a live fault: the Portainer stack creation instructions still named deploy/stack.yaml as the compose path. That file was removed, so anyone recreating the stack from these instructions would have failed. It names docker-compose.yml now, with the reason it stays at the root. ROADMAP.md keeps the paths its closed findings were written with, and says so at the top. Those entries record where a fault was when it was found; rewriting them to match a later layout would make the record less true, not more. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2.5 KiB
2.5 KiB
Production release checklist
Every item is required. A checked box records reviewed evidence; it is not a
substitute for production_preflight.py, CI, staging acceptance, or change approval.
Application and external contracts
docs/PRODUCTION_INPUTS.mdhas owners, decisions, and evidence for every item.- Production R2, freight, Mercado Pago, Tiny/Olist, and WhatsApp adapters have sandbox contract tests and least-privilege credentials.
- Payment webhook authenticity, replay handling, and idempotency are tested.
- Docker secret
*_FILEloading is implemented and tested without logging values. - Production account verification/recovery and the length/grade authority flow are approved.
- No factory automation or automatic print pre-flight was added by inference.
Platform and recovery
- DNS/TLS proxy routes and firewall rules are approved; only Site and Kanban have published web ports.
- External, versioned Swarm secrets exist and match the configured names.
- The PostgreSQL volume is encrypted/backed up and pinned to the labeled node.
- Scheduled offsite database/object backups and an isolated restore rehearsal pass.
- ClamAV signatures are current and have a controlled update/rebuild process.
- Central alerts, logs, clocks, capacity, and on-call ownership are verified.
Release and deploy
- Protected Gitea runner,
mainbranch, registry permissions, and variables are reviewed. - Base, database, and scanner images use approved immutable digests; application SHA tags remain pullable and the digest resolved by each deployment is recorded.
- Full regressions and production preflight pass on the exact release commit.
- HIGH/CRITICAL Trivy findings are fixed or formally risk-accepted with evidence.
- Staging acceptance passes with provider sandboxes and production-like topology.
- Four production approval variables equal
approvedonly after their reviews. - The generated
docker stack configcontains no secret values or placeholders. - Health probes, monitoring, rollback, and a backup restore are observed in staging.
- The Portainer webhook redeploys the one
dtf-cloudstack and post-deploy HTTPS health probes pass.
Rollback
- Previous application image digests remain pullable.
- Portainer rollback by full commit
IMAGE_TAGhas been rehearsed; it does not roll back the database. - Database migration forward/restore ownership and maintenance procedure are approved.