Skip to content

Deployment

This guide covers how changes move from a local branch through to production, including the CI/CD pipeline, environment setup, and what to do in an emergency. If anything is missing or out of date, submit a request via the Wiki Update Requests list in ClickUp.


Environments

Environment Purpose Access
Local Individual developer machines Developer only
Development (Staging) Integration testing and pre-release validation Engineering team
Production Live platform serving real brands and customers Restricted

All changes must be tested in the development environment before being deployed to production. Production data must never be copied to lower environments.


Standard Deployment Flow

Feature branch
Pull request opened on GitHub
CI pipeline runs (lint, tests, build)
CTO reviews and approves PR
Merge to main
GitHub Actions deploys to development (staging)
Verify on staging
Deploy to production via DuploCloud / GitHub Actions

Step by step

  1. Create a branch from main with a descriptive name (e.g. feature/storefront-duplication, fix/cart-recipient-validation)
  2. Open a pull request on GitHub once your changes are ready for review
  3. CI runs automatically — linting, tests, and build checks must pass before review
  4. CTO reviews and approves — all PRs require approval from Joshua Curci before merging
  5. Merge to main — once approved, merge the PR
  6. GitHub Actions deploys to staging automatically on merge to main
  7. Verify on staging — confirm the change works correctly in the development environment
  8. Deploy to production — trigger the production deployment via the pipeline once staging is verified

CI/CD Pipeline

The platform uses GitHub Actions for all CI/CD. Workflows are defined in .github/workflows/.

On every pull request: - Linting and type checks run - Unit and integration tests run - Build is verified

On merge to main: - Staging deployment is triggered automatically - The Claude Project sync notification is sent (see Claude Project Sync)

Production deployments are managed through DuploCloud, which handles infrastructure orchestration on AWS.


Deployment Freeze

No large-scale or disruptive deployments are permitted between 1 October and 1 January.

This freeze period covers the peak corporate gifting season. Permitted exceptions include critical security patches and urgent bug fixes, which require CTO approval.

See the full Deployment Windows and Release Policy for details on what qualifies as large-scale and how to request an exception.


Hotfix / Emergency Deployments

If a critical bug or security issue needs to go to production outside the normal flow:

  1. Create a hotfix/ branch directly from main
  2. Make the minimal fix required — do not bundle unrelated changes
  3. Open a PR and notify Joshua immediately via Slack
  4. CTO reviews and approves — the standard review requirement still applies
  5. Merge and deploy
  6. A retrospective note must be added to the relevant ClickUp task within 48 hours

See the Change Management SOP for the full emergency change process.


DuploCloud

Infrastructure is managed through DuploCloud, which provides:

  • Environment configuration for development and production
  • Secret and environment variable management
  • AWS service management (ECS, S3, SQS, KMS)
  • Deployment orchestration

Access to DuploCloud is restricted to engineers who need it. Contact Joshua to request access.


Environment Variables in Production

Production secrets and environment variables are managed through DuploCloud — they are not stored in the repository or in .env files on servers.

When a new environment variable is required: 1. Add it to the relevant .env.example file in the repo (with a placeholder value, never a real secret) 2. Add the real value in DuploCloud for both the development and production environments 3. Note the new variable in the PR description so it is not missed during deployment


Checking Deployment Status

  • GitHub Actions — check the Actions tab in the repository for pipeline status
  • Sentry — monitor for new errors after a deployment at sentry.io
  • AWS CloudWatch — infrastructure-level logs and metrics

After any significant deployment to production, keep an eye on Sentry for 15-30 minutes for unexpected error spikes.