Deployment Plan

Cut Flowers Monitoring System Deployment Plan

1. Document Control

• Project: Thunder Bay Cut Flowers Monitoring System
• Date: 2026-04-14
• Environment scope: Staging and Production
• Deployment owner: Release Manager
• Status: Draft for team review

2. Deployment Goals and Success Criteria

Goals

• Deploy the backend API, frontend, database schema, CV pipeline, and device upload path as one working system.
• Preserve data integrity and secure authentication for users and devices.
• Enable ongoing operations (monitoring, backups, alerting support, and incident response).

Success Criteria

• User can register, log in, and view dashboard/data pages.
• Device can upload JPEG images with API key authentication.
• Record ingestion, CV scoring, and optional email alerting work end-to-end.
• Database backups and restore procedure are validated.
• Support team can execute runbook tasks without developer intervention.

3. Deployment Scope and Architecture Summary

In Scope

• Node.js Express backend
• Next.js frontend static export hosted by backend
• PostgreSQL database and DDL/migrations
• Python CV analysis dependencies and runtime
• SMTP-based email alerting configuration
• ESP32 device provisioning and API key onboarding

Out of Scope

• Hardware manufacturing or sensor redesign
• Large-scale horizontal autoscaling architecture changes
• New feature development beyond deployment readiness

4. Required Equipment and People (Roles)

4.1 Equipment and Software

• Application server VM or physical host
• PostgreSQL server host (can be same host for small deployment)
• HTTPS termination layer (reverse proxy/load balancer with TLS certificates)
• Secure secrets storage method (environment variables and restricted access)
• Backup storage target (off-host and/or cloud object storage)
• CI/CD runner or deployment workstation
• ESP32-S3 camera devices with firmware tooling
• Network access to NTP, sunrise-sunset API, and SMTP provider

4.2 Roles and Responsibilities

Role	Primary Responsibility During Installation	Primary Responsibility During Operations
Release Manager	Own deployment checklist, go/no-go decision, timeline control	Own release calendar and rollback decisions
Backend Engineer	Configure API service, routes, env vars, process startup	Triage API incidents, patch backend defects
Frontend Engineer	Build/export client bundle, verify page routing and API base URL	Support UI regressions and compatibility issues
Database Administrator	Provision DB, run DDL/migrations, validate indexes and backups	Own backup/restore, data integrity checks, SQL performance
DevOps/SRE	Provision infrastructure, TLS, logging, monitoring, service restart policy	Uptime, alerting, scaling, capacity planning
QA Engineer	Execute smoke/regression/UAT scripts	Run post-release verification and defect triage
Support Analyst	Validate support runbook and user onboarding flow	First-line support and escalation handling
Security Lead	Validate secrets handling and auth hardening	Review vulnerabilities and rotate credentials
Firmware/Device Technician	Flash firmware, configure Wi-Fi/API key, field test uploads	Replace/re-provision failed devices
Trainer	Deliver end-user and support training sessions	Refresher training and knowledge base updates

5. Systems, Procedures, and Roles for Ongoing Operation

5.1 Core Operating Systems and Services

• Application process manager for Node service (service unit or equivalent)
• PostgreSQL service with restricted DB user permissions
• Scheduled backup job and restore validation workflow
• Log aggregation and retention policy for API, DB, and CV subprocess logs
• Incident ticketing and escalation workflow

5.2 Operational Procedures

Backups and Restore

• Daily logical backup of database.
• Weekly restore test into non-production environment.
• Backup retention policy: 30 daily, 12 monthly snapshots.
• Owner: Database Administrator.

CV and ETL-like Processing Supervision

• Ingestion endpoint acknowledges upload immediately, then performs asynchronous image analysis and persistence.
• Monitor CV timeout/failure rates and fallback-score usage.
• Maintain Python dependencies in a pinned environment.
• Owner: Backend Engineer + DevOps/SRE.

Alerting Operations

• Validate SMTP credentials, domain restrictions, and score threshold settings.
• Monitor delivery failures and cooldown behavior.
• Owner: Support Analyst + Backend Engineer.

Security Operations

• Rotate JWT secret, device API keys (as required), and SMTP credentials.
• Enforce production setting to prevent insecure auth fallback.
• Owner: Security Lead + DevOps/SRE.

6. Initialization Plan (Configuration, Accounts, and Data)

6.1 Environment Configuration Baseline

Configure and validate at minimum:

• API service:
  • ENVIRONMENT
  • PORT
  • JWT_SECRET
  • DB_NAME
  • DB_USER
  • DB_PASSWORD
  • CV_ANALYSIS_ENABLED
  • CV_TIMEOUT_MS
  • CV_FALLBACK_SCORE
  • ALERT_EMAIL_ENABLED
  • ALERT_EMAIL_SCORE_THRESHOLD
  • ALERT_EMAIL_COOLDOWN_HOURS
  • ALERT_EMAIL_GMAIL_USER
  • ALERT_EMAIL_GMAIL_APP_PASSWORD
  • ALERT_EMAIL_FROM
• Frontend:
  • NEXT_PUBLIC_API_BASE_URL
• CV scripts:
  • GEMINI_API_KEY
  • GEMINI_MODEL (optional)
  • CV_ANALYSIS_ENABLED (optional, defaults to true; set false for Gemini-only scoring)
• Device firmware secrets:
  • Wi-Fi SSID/password
  • device API key
  • server name/path
  • latitude/longitude

6.2 Account Initialization

• Create database role and database owner with least privilege.
• Create first admin/operations user account in application.
• Create deployment service account for CI/CD if used.
• Create support staff user accounts for validation access.

6.3 Data Initialization

• Run base schema script.
• Run migration script for user settings JSON field if needed.
• Optionally seed demo images/data only in non-production.
• Validate monitor, user, and association tables with test records.

7. Stepwise Installation Procedure

Phase A: Pre-Deployment Readiness

1. Confirm release window, freeze policy, and communication plan.
2. Verify access to infrastructure, DB, email provider, and firmware tooling.
3. Verify TLS certificates and DNS records.
4. Create final deployment artifact versions and checksums.

Estimated duration: 2 to 3 hours.

Phase B: Infrastructure Provisioning

1. Provision application host and database host.
2. Install Node.js runtime and required OS packages.
3. Install Python runtime and virtual environment for scripts dependencies.
4. Provision storage path for uploaded images with correct permissions.

Estimated duration: 2 to 4 hours.

Phase C: Database Setup

1. Create database role/user and database.
2. Execute base DDL script.
3. Execute incremental migration scripts (if not already included).
4. Run schema validation queries (tables, indexes, constraints).

Estimated duration: 1 to 2 hours.

Phase D: Application Deployment

1. Deploy repository code to target host.
2. Install backend dependencies.
3. Install frontend dependencies and generate static export.
4. Verify backend serves static frontend output path.
5. Configure process manager/service startup.

Estimated duration: 2 to 3 hours.

Phase E: Configuration and Secrets

1. Create production environment file entries using secure secret injection.
2. Set JWT secret and enforce production environment mode.
3. Configure DB credentials and test connection.
4. Configure email credentials and threshold/cooldown values.
5. Configure CV credentials and timeout.

Estimated duration: 1 to 2 hours.

Phase F: Device Onboarding

1. Create monitor records or claim flow path for each production device.
2. Flash firmware and configure device secrets (server/API key/location).
3. Connect devices to Wi-Fi and validate first upload.
4. Confirm records and images appear in app.

Estimated duration: 30 to 60 minutes per device batch.

Phase G: Validation and Go-Live

1. Run smoke tests:
   • register/login/logout
   • monitor create/claim
   • recent/range data APIs
   • image retrieval
2. Trigger controlled test upload and verify record + optional alert.
3. Execute UAT sign-off checklist.
4. Announce go-live and open hypercare period.

Estimated duration: 2 to 3 hours.

8. Time Estimates by Major Piece

Major Piece	Estimate	Owner
Planning and readiness	2 to 3 hours	Release Manager
Infrastructure setup	2 to 4 hours	DevOps/SRE
Database provisioning and migration	1 to 2 hours	DBA
App build and deployment	2 to 3 hours	Backend + Frontend Engineers
Environment/secrets configuration	1 to 2 hours	DevOps/SRE + Security
Device provisioning and first uploads	0.5 to 1 hour per batch	Device Technician
Validation, UAT, go-live	2 to 3 hours	QA + Release Manager
Hypercare (post-release)	1 to 2 business days	Support + Engineering

Total initial deployment estimate (excluding hypercare): 10.5 to 18 hours plus device batch time.

9. Training Plan for Users and Support Personnel

9.1 End-User Training (Growers/Operators)

• Format: Live walkthrough plus short written guide.
• Duration: 60 minutes.
• Topics:
  • login and account basics
  • dashboard interpretation
  • data page filters and historical analysis
  • monitor selection and basic settings
  • understanding alerts and response actions
• Validation: completion quiz or practical checklist.

9.2 Support Team Training

• Format: Runbook workshop and scenario drills.
• Duration: 90 to 120 minutes.
• Topics:
  • common incidents (login issues, missing data, device offline)
  • log locations and triage flow
  • escalation matrix and SLA targets
  • credential and key rotation process
  • backup/restore request handling
• Validation: incident simulation with pass/fail criteria.

9.3 Technical Operations Training

• Format: Deep-dive handoff for DevOps/DBA/Engineering.
• Duration: 2 to 3 hours.
• Topics:
  • deployment steps and rollback trigger points
  • DB maintenance and restore testing
  • CV dependency and timeout management
  • alerting configuration and health checks

10. Backout Plan (Rollback if Deployment Fails)

10.1 Rollback Triggers

Initiate backout if any of the following occurs during deployment window:

• Authentication failures across majority of test users
• Device uploads failing at high rate
• Database migration failure causing schema incompatibility
• Critical regression in record retrieval or image serving
• Unrecoverable security misconfiguration (secrets exposure risk)

10.2 Backout Procedure

1. Announce deployment rollback and freeze new changes.
2. Stop current application service.
3. Repoint service to previous known-good release artifact.
4. Restore previous environment variable set from secure backup.
5. If DB schema/data changed incompatibly:
   • restore latest pre-deployment backup into production DB
   • validate integrity and application connectivity
6. Run smoke validation on restored version.
7. Confirm service restoration and communicate status.
8. Open postmortem task and capture root cause/actions.

10.3 Recovery Time Targets

• Application rollback target: 30 to 60 minutes
• Database restore rollback target: 60 to 120 minutes (depends on backup size)

11. Communications and Governance

• Pre-deployment notice: 3 to 5 business days before release.
• Deployment start/finish notifications: real-time in team channel.
• Incident communication cadence during rollback: every 15 to 30 minutes.
• Final release report: within 1 business day.

12. Appendices

Appendix A: Quick Pre-Go-Live Checklist

• All required environment values are set and validated.
• DB schema and migrations are complete.
• Frontend static output is present and served correctly.
• Device API keys are provisioned and tested.
• Backup and restore test is successful.
• Support team confirms runbook readiness.
• Go/no-go approval recorded.