Skip to content

Deploy Process (CQ)

Owner: [Senior Engineer TBD] | Updated: 2026-02-05

Purpose

Deploy small and frequently. Get your work onto an environment where everyone can see and test it—not stuck on your local machine.

Philosophy

Deploy small: Small changes are easier to test, easier to debug, easier to rollback.

Deploy frequently: Waiting to deploy creates big, risky releases. Ship often.

Deploy visibly: If only you can see it, it's not deployed. Everyone should be able to test.

Environments

Local — Your machine only. Good for initial development.

Staging/Preview — Shared environment. Team can see and test. Deploy here early and often.

Production (Beta Flag) — Real users, but feature is flagged. Beta testers can use it.

Production (Full) — Everyone sees it. Feature is complete and approved.

When to Deploy Where

Alpha phase: Deploy to staging/preview so stakeholders can review.

Beta phase: Deploy to production under beta flag. Real users start using it.

Final phase: Remove beta flag. Full production release.

Hotfix: Deploy directly to production after quick test.

Deploy Checklist (Basic)

Before deploying:

  • Code is committed and pushed
  • Tests pass (if applicable)
  • Self-tested the happy path
  • No obvious console errors
  • Linked to ClickUp task

After deploying:

  • Verify it works on the deployed environment
  • Post in #cq-product if it's a notable change
  • Update ClickUp task status

Beta Flag Management

Adding beta flag: Feature is ready for real users but not everyone. Flag limits who sees it.

Removing beta flag: Erik approves Final → remove flag → everyone sees it.

Only remove beta flag after Erik approval.

Rollback

If production breaks after deploy:

  1. Don't panic
  2. Rollback to previous version (revert commit, redeploy)
  3. Post in #cq-product: "Rolled back [feature] due to [issue]. Investigating."
  4. Fix the issue
  5. Redeploy when fixed

Rollback first, debug second. Don't leave production broken while you investigate.

Technical Details

[To be filled in by Senior Engineer]

  • Git workflow (branch naming, merge process)
  • CI/CD pipeline details
  • How to deploy to staging
  • How to deploy to production
  • How to rollback
  • Environment variables / secrets management
  • Database migration process

FAQ

Q: How often should I deploy? A: As often as you have working code to show. Daily is good. Multiple times a day is fine.

Q: Can I deploy without review? A: To staging, yes. To production, follow the beta flag process and get appropriate approvals.

Q: What if I break staging? A: Fix it quickly. Staging breaking is okay—that's what it's for. Production breaking is not okay.

Q: What if my deploy is stuck/failing? A: Post in #cq-product. Don't suffer in silence.

Summary

Deploy small. Deploy frequently. Get your work visible.

Local only = not deployed. Staging = team can see. Production (beta) = users can test. Production (full) = everyone sees.

Don't let code sit on your machine. Ship it.