Engineering

Deployment Workflow

Never push directly to the main branch. All work must be done on feature branches.

Create a new branch for every feature, fix, or task using these prefixes:

feat/feature-slug    # New features
fix/bug-description  # Bug fixes
chore/task-name      # Maintenance, refactoring, deps

Example:

git checkout -b feat/slack-integration
git checkout -b fix/login-error
git checkout -b chore/update-deps

Deployment Flow

  1. Create and push your branch: git push origin feat/your-feature

  2. Test your changes locally using pnpm dev

  3. Open a pull request when ready for review

  4. Wilson pulls your branch and tests locally

  5. After code review and approval, merge to main → automatic production deployment to Railway

All testing happens locally before merging. No preview deployments are used.

Code Review Process

All code requires review before merging:

  1. Push your branch and open a PR on GitHub

  2. Tag Wilson for review

  3. Wilson pulls your branch and tests locally

  4. Address feedback and push updates

  5. Once approved, Wilson or you can merge

Keep PRs small and focused. One feature or fix per branch makes reviews faster.

Main Branch Protection

The main branch is protected and deploys directly to production. Only merge via approved pull requests, direct pushes are blocked.

Troubleshooting

Can't push to main? This is intentional. Create a branch and open a PR.

Local tests passing but production fails? Check Railway logs in the dashboard for env var mismatches or build errors. Contact Wilson.

Merge conflicts? Pull latest main into your branch: git pull origin main, resolve conflicts, then push.

Was this helpful?