LogoLogo
  • 👋Cal.com Handbook
  • The Company
    • ❓What is Cal.com?
    • 📈Mission, Vision and Values
    • 🅰️Glossary
    • 📈Organization Chart
  • HR & Careers
    • 👷Contract-to-hire trials
    • 🛫Onboarding
    • 🏆IC Levels
      • ⛰️Engineering Levels
        • 🕵️IC1 Engineer (Code Cadet)
        • 👷‍♀️IC2 Engineer (Code Craftsperson)
        • 🧘‍♀️IC3 Engineer (Code Connoisseur)
        • 🧙‍♂️IC4 Engineer (Code Wizard)
    • 💡Sharing your views
    • 💸Bonus & Equity Structure
  • Policies
    • 🏖️Vacations
    • 💳Expenses
    • 🗣️Communications
  • Engineering
    • 🔔Managing Notifications
    • ⭐Valuable Bookmarks
    • 🐛How to report issues
    • 💻How we work on Tickets
    • 🔥What to do during Emergencies
    • ✅PR Reviews
    • ☑️Self-reviews
    • 📚Keeping Docs up-to-date
    • 🌐HTTPS & Subdomains
    • 🎯Best practices
      • Data fetching
      • Avoid Prop Drilling
      • Prefer defaultHandler for simple API handlers
      • Prefer inferred types over explicit ones
      • Prefer early returns
      • Avoid comparing multiple values with `includes`
      • Validate using zod instead of type casting
      • Prefer Composition over Prop Drilling
      • Prefer ternaries over Short Circuiting “&&” for React Components
      • Don't modularize prematurely
      • Only select data you need
      • Disallowing the use of unrestricted Metadata fields
      • E2E Tests Best Practices
    • 💻Codebase
      • 🔓Keeping the lock file in sync
      • 🚫Git Private Submodules
      • 🏎️Monorepo / Turborepo
      • 🌝Deploying to Production
      • ☁️Deployment
      • 💻Debug Desktop App
      • 🚩Enabling/Disabling Features
    • 🔺Resolving failed migration on Vercel Preview
    • 🔦Cal.com Status Page
  • Customer Success
    • 💟Tone
  • Marketing
    • 🎬Media
    • ☝️How to add a new Tip to Sidebar
  • 🤲Sales
    • Operations Stack
Powered by GitBook
On this page
  • Steps to release a new version
  • Check for migrations

Was this helpful?

  1. Engineering
  2. Codebase

Deploying to Production

PreviousMonorepo / TurborepoNextDeployment

Last updated 1 year ago

Was this helpful?

We merge all reviewed and approved PR's to main and then merge to the production branch to start the automated deployment process.

Branch
Deployed
Envirorment

Pull Requests

*cal.vercel.app

Preview

main

app.cal.dev

Staging

production

app.cal.com

Production

Steps to release a new version

  1. according to semver standards, stage it in git and "Commit changes" directly to the main branch.

  2. Create a new release in GitHub:

  3. Type the new version and hit "Create new tag: vX.Y.Z on publish"

  4. Use the "Create auto generated release text" button

  5. Publish release

  6. Profit!

Check for migrations

This is important. When doing a release make sure you run proper migrations first.

Also, important sidenote, if a migration is adding a new table. We need to re-grant proper permissions to each created username that are currently being used. Run these commands for each username (Replcing <USERNAME> with the proper one):

GRANT ALL PRIVILEGES ON ALL SEQUENCES IN SCHEMA public TO <USERNAME>;
GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA public TO <USERNAME>;
💻
🌝
Bump "version" in apps/web/package.json
https://github.com/calcom/cal.com/releases/new