CROP
Shared

Production Pre-Deployment Checklist

> Purpose: This checklist ensures that code changes are production-ready before deployment. > Target: Bun + Hono + TypeScript monorepo ()

Production Pre-Deployment Checklist

Purpose: This checklist ensures that code changes are production-ready before deployment. Target: Bun + Hono + TypeScript monorepo (crop-microservices)


1. Security & Secrets

1.1 No Hard-Coded Secrets

  • No API keys, tokens, or passwords in source code
  • No secrets in configuration files (JSON, YAML, TOML)
  • No secrets in test files or fixtures
  • All secrets loaded from environment variables or secret manager
  • No .env files committed (check .gitignore)

1.2 Authentication & Authorization

  • All endpoints have proper authentication checks
  • Authorization rules enforce least-privilege access
  • No debug/backdoor endpoints in production code
  • Rate limiting configured for public endpoints

1.3 Input Validation & Sanitization

  • All user inputs are validated (type, format, range)
  • SQL injection protection (parameterized queries)
  • XSS prevention (output encoding, CSP headers)
  • File upload validation (type, size, content)
  • Command injection prevention (no shell execution with user input)

2. Code Quality & Testing

2.1 Type Safety

  • No any types without justification
  • TypeScript strict mode enabled
  • All functions have return type annotations
  • No type assertions (as) without safety checks

2.2 Error Handling

  • All async operations have proper error handling
  • No unhandled promise rejections
  • Errors logged with sufficient context
  • User-facing errors don't leak sensitive info
  • HTTP error codes match actual error scenarios

2.3 Testing

  • New features have unit tests
  • Critical paths have integration tests
  • All tests pass locally (bun test)
  • No skipped/disabled tests without documented reason
  • Test coverage for edge cases and error scenarios

3. Performance & Scalability

3.1 Database Queries

  • No N+1 query problems
  • Proper indexes on queried fields
  • Pagination for large result sets
  • Query timeouts configured
  • Connection pooling configured correctly

3.2 API Efficiency

  • Response payloads are reasonably sized
  • Heavy operations run asynchronously
  • Caching used where appropriate
  • Rate limiting prevents abuse

3.3 Memory & Resources

  • No memory leaks (streams closed, listeners removed)
  • File handles properly closed
  • Timeouts set for external API calls
  • Graceful shutdown handlers implemented

4. Observability & Monitoring

4.1 Logging

  • Appropriate log levels (error, warn, info, debug)
  • Structured logging (JSON format preferred)
  • No sensitive data in logs (PII, secrets, tokens)
  • Request IDs for tracing distributed requests
  • Critical operations logged with context

4.2 Metrics & Alerts

  • Key business metrics instrumented
  • Error rates tracked
  • Performance metrics (latency, throughput)
  • Alerts configured for critical failures

5. API & Integration Contracts

5.1 API Design

  • OpenAPI/Swagger documentation up-to-date
  • Breaking changes avoided or properly versioned
  • Backward compatibility maintained
  • Response schemas documented and validated
  • Proper HTTP methods (GET, POST, PUT, DELETE, PATCH)

5.2 External Dependencies

  • Third-party API failures handled gracefully
  • Circuit breakers for flaky services
  • Retry logic with exponential backoff
  • Fallback strategies for critical paths

6. Configuration & Environment

6.1 Environment Variables

  • All required env vars documented
  • Default values set for non-sensitive configs
  • Environment-specific configs separated
  • No development-only code in production paths

6.2 Feature Flags

  • New features behind feature flags if needed
  • Flag states documented
  • Rollback plan for feature flag changes

7. Deployment & Infrastructure

7.1 Docker & Containers

  • Dockerfile uses non-root user
  • Multi-stage builds for smaller images
  • Health check endpoint implemented
  • Readiness probe configured
  • Resource limits defined (CPU, memory)

7.2 Cloud Run / GCP

  • Service configuration reviewed
  • Auto-scaling parameters set appropriately
  • IAM permissions follow least privilege
  • Secrets managed via Secret Manager

7.3 CI/CD Pipeline

  • All pipeline checks pass (lint, test, build)
  • Pre-commit hooks executed
  • Dependency security scan (e.g., bun audit)
  • Docker image security scan (e.g., Trivy)

8. Data & Migrations

8.1 Database Migrations

  • Migration scripts tested in staging
  • Rollback plan exists
  • Backward-compatible schema changes
  • Data integrity constraints maintained

8.2 Data Handling

  • No destructive operations without confirmation
  • Bulk operations batched appropriately
  • Data retention policies respected
  • GDPR/privacy compliance maintained

9. Documentation

9.1 Code Documentation

  • Complex logic explained with comments
  • Public APIs have JSDoc/TSDoc
  • README updated if behavior changes
  • Breaking changes documented in changelog

9.2 Runbooks & Procedures

  • Deployment runbook updated
  • Rollback procedure documented
  • Known issues and workarounds listed
  • On-call escalation paths clear

10. Final Checks

10.1 Pre-Deployment

  • Peer review completed and approved
  • Smoke tests passed in staging
  • Load tests passed (if applicable)
  • Rollback plan prepared

10.2 Post-Deployment

  • Health check endpoints returning 200 OK
  • Key metrics within expected ranges
  • No error spikes in logs or APM
  • Stakeholders notified of deployment

Quick Command Reference

# Run all tests
bun test

# Type check
bun run typecheck

# Lint and format
bun run lint
bun run format

# Security audit
bun audit
trivy image <image-name>

# Build all services
bun run build

Severity Levels

When reviewing this checklist:

  • ❌ BLOCKER: Must be fixed before production. Security risk or critical bug.
  • ⚠️ WARNING: Should be fixed but can ship with documented risk. Technical debt or minor issue.
  • ✅ PASS: Item meets production standards.

Last Updated: 2025-01-16 Owner: Engineering Team Review Frequency: Before every production deployment

On this page