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¶
- Create a branch from
mainwith a descriptive name (e.g.feature/storefront-duplication,fix/cart-recipient-validation) - Open a pull request on GitHub once your changes are ready for review
- CI runs automatically — linting, tests, and build checks must pass before review
- CTO reviews and approves — all PRs require approval from Joshua Curci before merging
- Merge to main — once approved, merge the PR
- GitHub Actions deploys to staging automatically on merge to
main - Verify on staging — confirm the change works correctly in the development environment
- 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:
- Create a
hotfix/branch directly frommain - Make the minimal fix required — do not bundle unrelated changes
- Open a PR and notify Joshua immediately via Slack
- CTO reviews and approves — the standard review requirement still applies
- Merge and deploy
- 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.