Skip to main content

Deployment Checklist: Drop — Fintech Payment App

Deployment Checklist: Drop — Fintech Payment App

Project: Drop — Remittance + QR Payments Version: 0.5.0 Date: 2026-02-23 Author: John (AI Director) Status: Approved Reviewers: Alem Bašić (CEO)

Document History

Version Date Author Changes
0.1 2026-02-23 John Initial draft — aligned to Phase 0.5 security hardening

Deployment Metadata

Field Value
Version 0.5.0
Target Environment Staging → Production (Fly.io, Stockholm)
Deployment Date TBD per release
Deployment Time 02:00–06:00 CET (off-peak window)
Deploy Engineer John (AI Director)
Approver Alem Bašić (CEO)
Deployment Type Standard
Change Request # CR-001
Rollback Version 0.4.x (previous stable)

1. Pre-Deployment Checklist

Code Quality Gates

  • Code reviewed and approved — all PRs in this release have ≥ 1 approval (Alem or John)
  • All unit tests passing — CI pipeline green on the release branch (npm run test → 40+ tests pass)
  • All integration tests passing — CI pipeline integration stage green (npm run test:integration)
  • Code coverage meets minimum — ≥ 80% overall; 100% for auth + transaction paths (Vitest coverage)
  • No HIGH/CRITICAL security findings — SAST scan clean; no open critical issues from security audit
  • No secrets detected — no .env values committed; secret scanning clean
  • Linting passes — npm run lint no errors in CI lint stage
  • TypeScript compiles — npm run type-check passes with zero errors

Staging Verification

  • Staging deployment complete — artifact deployed to https://drop-staging.fly.dev/
  • E2E tests passing on staging — Playwright suite green (3 projects: user-flows, full-flows, input-chaos)
  • Manual QA sign-off obtained — Validator agent has reviewed new features
  • Performance baseline not degraded — P95 API within 10% of baseline (api-benchmarks.test.ts targets)
  • Visual regression checks passed — UI screens match Figma-make export mockups
  • Health endpoint responding — GET https://drop-staging.fly.dev/api/health returns {"status":"ok"}

Database & Migrations

  • Database migrations reviewed — SQL reviewed by a second person (John + Alem)
  • Migrations tested on staging — ran successfully; SQLite dev / PostgreSQL staging verified
  • Down/rollback migration tested — migrate down executes without errors on staging
  • Migration script idempotent — safe to run twice without errors
  • Estimated migration time on production documented: < 2 min (schema-only, no data migration in Phase 0.5)
  • Data backup taken before migration — Fly.io volume snapshot taken; backup ID recorded
  • Pass-through model verified — users table has NO balance column; cards table has NO card_number or cvv columns (db.test.ts passes)

Environment & Configuration

  • All environment variables documented — updated in Vaultwarden (vault.basicconsulting.no)
  • New secrets provisioned — JWT_SECRET, DATABASE_URL, SUMSUB_API_KEY (mock), BAAS_API_KEY (mock) set in Fly.io secrets
  • Configuration changes reviewed — no unintended env var drift from staging
  • External API keys — Sumsub and BaaS keys are mock/sandbox credentials (MVP only; real in Phase 2)
  • NEXT_PUBLIC_SERVICE_MODE — set to mock for MVP; never live until BaaS partnership confirmed
  • NEXT_PUBLIC_FEATURE_FLAGS — Cards feature flag OFF in production
  • BankID keys — Phase 2 only; not required for MVP

Feature Flags

  • Feature flags configured — new features default OFF in production
  • Cards feature flag = OFF — requires card partner onboarding (Phase 3)
  • BankID flag = OFF — Phase 2 feature; DOB validation active in MVP
  • Kill switches in place for QR payments and Remittance (env var toggle)
  • Feature flag audit complete — no stale flags from previous releases

Rollback Readiness

  • Rollback plan documented — see Section 5 and rollback-plan.md
  • Previous version artifact available — drop-app:v0.4.x Docker image in Fly.io registry
  • Rollback tested on staging — flyctl deploy --image drop-app:v0.4.x tested successfully
  • Rollback owner assigned — John (AI Director) is available during deployment window
  • Rollback time < 5 minutes confirmed (Fly.io blue/green instant rollback)

Operational Readiness

  • On-call engineer notified — Alem Bašić aware and available during deployment window
  • Deployment window confirmed — 02:00–06:00 CET (off-peak; lowest user traffic for Norway corridor)
  • Monitoring dashboards open — Fly.io metrics dashboard ready
  • Slack channel ready — #drop-deploy on alai-talk.slack.com
  • Change request approved — CR-001 approved by Alem Bašić

2. During Deployment

Step Time Actor Status Notes
Announce deployment start in #drop-deploy Slack John "Deploying Drop v0.5.0 to production"
Enable maintenance mode (if required) John Set MAINTENANCE_MODE=true env var
Trigger deployment: flyctl deploy --app drop-app John Monitor Fly.io deployment logs
Monitor deployment progress John Watch for health check failures
Run database migrations (if applicable) John npm run db:migrate on Fly.io console
Verify migration success: flyctl ssh console -a drop-app John Check no orphaned records
Confirm new instances healthy (health checks green) John Fly.io load balancer shows 2/2 healthy
Confirm all instances running new version John flyctl status --app drop-app
Run smoke tests Validator npx playwright test --project=user-flows
Verify health endpoint: curl https://getdrop.no/api/health John Expect {"status":"ok","db":"connected"}
Disable maintenance mode (if enabled) John Set MAINTENANCE_MODE=false
Announce deployment complete in #drop-deploy John Include version and health status

3. Post-Deployment Checklist

Immediate Verification (First 15 Minutes)

  • Health checks passing — GET /api/health returns 200 with {"status":"ok","db":"connected"}
  • Smoke tests pass — Playwright user-flows suite green on production
  • Critical user journey manual test — manually verify: Registration → OTP → PIN → Login → Dashboard
  • Error rate normal — < 0.1% on Fly.io metrics dashboard
  • P99 latency normal — < 500ms (standard endpoints); < 1,000ms (bcrypt operations)
  • Database connections normal — no connection pool saturation
  • No unexpected errors in logs — flyctl logs --app drop-app shows clean logs

Feature Validation (First 30 Minutes)

  • Registration flow functional — test with valid Norwegian phone (+47) and DOB ≥ 18
  • Login + JWT cookie set — httpOnly, SameSite=Strict, 7-day expiry verified
  • Remittance flow functional — test with mock BaaS; fee calculation correct (0.5%)
  • QR payment flow functional — test with mock merchant; fee correct (1%)
  • Exchange rates returning — GET /api/rates returns 6 NOK corridors (RSD, BAM, PKR, TRY, PLN, EUR)
  • Cards feature flag OFF — no Cards UI exposed
  • Rate limiting active — 10+ auth requests → 429 response

Monitoring Setup (First 60 Minutes)

  • Performance baseline compared — P95 matches staging baseline
  • CPU and memory normal — Fly.io metrics; no upward trend
  • Stakeholders notified — Alem Bašić notified via MCP email ([email protected] → [email protected])
  • Release notes published — release-notes.md updated
  • Security audit score maintained — no regression from Phase 0.5 hardening (target: ≥ 80/100)

4. Rollback Procedure (Quick Reference)

Rollback triggers (any one sufficient):

  • Smoke tests fail after deployment
  • Error rate > 1% for > 5 consecutive minutes
  • P99 > 2,000ms sustained
  • Data integrity issue detected (e.g., balance column found in users table)
  • Security vulnerability actively exploited

Rollback authorization: John (AI Director) or Alem Bašić (CEO)

Rollback steps:

# 1. Announce in #drop-deploy: "Initiating rollback to v0.4.x"

# 2. Trigger Fly.io rollback (instant, < 2 min):
flyctl deploy --app drop-app --image drop-app:v0.4.x

# 3. If DB migration was included — run down migration:
flyctl ssh console -a drop-app -C "npm run db:migrate:down"

# 4. Verify rollback:
curl https://getdrop.no/api/health
npx playwright test --project=user-flows

Expected rollback time: 2–5 minutes (Fly.io blue/green) Full rollback procedure: rollback-plan.md

5. Emergency Deployment Process

Emergency deployments require:

  1. Sign-off from Alem Bašić (CEO) or John (AI Director)
  2. At least 1 code reviewer (can be async if truly urgent)
  3. Staging deployment and smoke test (cannot be skipped — even for emergencies)
  4. Enhanced post-deploy monitoring for 4h
  5. Full retroactive change request within 24h of deployment

Emergency deployment allowed: Security vulnerabilities (e.g., auth bypass), data loss bugs, P1 service outages

6. Deployment Window & Blackout Periods

Standard deployment window: Tuesday–Thursday, 02:00–06:00 CET Emergency deployments: Any time, with CEO or AI Director approval

Blackout periods (no production deployments):

Period Dates Reason
Finanstilsynet submission window TBD Regulatory review — no changes during evaluation
BaaS partner onboarding TBD (Phase 2) Partner integration stability required
Norwegian bank holidays Per year Minimal engineering support available

Sign-Off

Pre-deployment confirmed by: John (AI Director) Deployment completed by: John (AI Director) Post-deployment verified by: Validator agent + John (AI Director)

Approval

Role Name Date Signature
Author John (AI Director) 2026-02-23 Approved (AI)
Tech Lead John 2026-02-23 Approved
AI Director (John) John 2026-02-23 Approved
CEO (Alem) Alem Bašić TBD

No comments to display

Back to top