Skip to Content
OperationsDeployments

Deployments

The inspection app deploys through Vercel. Preview and production environments use different database and Salesforce settings, so deployment notes must always state which environment is being discussed. This page exists because the app can write to Salesforce, and confusing preview, sandbox, production databases, or production Salesforce credentials can create real operational errors.

Inspection app deployment model

  • Preview branches build automatically on Vercel.
  • Production deploys from the production branch used by the app repository.
  • Preview deployments can use PREVIEW_* database variables.
  • Production Salesforce writes must be handled carefully and should not be confused with sandbox preview testing.

Environment model

Feature branch ── deploys to ── Vercel preview Preview deployment ── should use ── preview database and sandbox-safe settings Production branch ── deploys to ── production app Production app ── writes to ── production Salesforce only when intended

Feature gates

Several features are switched on by environment variable rather than by role, so a workflow can be piloted in one division before it reaches everyone. The direction each gate fails is a deliberate design decision, and they do not all fail the same way.

VariableDefault when unsetControls
RENOVATION_WORKFLOW_DIVISIONSOff — fails closedThe review → proposal pipeline and Manager Requests, per division
SSO_ONLY_EMAIL_DOMAINSNo restriction — fails openWhich domains must sign in with Google
FIELD_SURVEY_PUSH_ENABLEDOffThe reno-field → Salesforce Field Survey push
SALESFORCE_ACCOUNT_CACHE_ENABLEDOffCustomer/pool pickers read the Postgres cache instead of live Salesforce

The two gates fail in opposite directions on purpose. A missing SSO_ONLY_EMAIL_DOMAINS must not lock people out of login, so it fails open. A missing RENOVATION_WORKFLOW_DIVISIONS must not expose an unproven workflow to every division, so it fails closed — unset or blank means nobody has it. Do not “fix” one to match the other.

A few operational notes:

  • RENOVATION_WORKFLOW_DIVISIONS is evaluated against the review’s division, not the viewer’s.
  • Turning a division off is a kill switch, not a delete. Rows stay; re-adding the division restores them.
  • Cancel outstanding Manager Requests before switching a division off. Cancel is gated by this variable, but the Level-5-only delete escalation is not — so afterwards there is no in-app way to clear them.
  • SALESFORCE_ACCOUNT_CACHE_ENABLED needs the cache seeded before it is switched on. A cold cache falls back to live Salesforce rather than showing an empty customer list.
  • Enable any of these on Preview, against the sandbox, before Production.

Docs deployment model

This docs portal deploys separately from the app at docs.ca-tools.io. That gives documentation updates their own preview URL and production release path.

Docs deployment should stay project-neutral. Adding a new product section, such as PoolTracker / Preseason, should not require a production deploy of that application. Conversely, shipping a production application change should not automatically imply the docs are current unless the relevant documentation change has also been reviewed and deployed.

Release discipline

Docs updates should cite the app version or commit they describe when behavior is version-sensitive. Operational guides should be reviewed after each major workflow change.

Pitfalls

  • Do not test production pricebook writes from a preview deployment unless the change was explicitly approved for production.
  • Do not assume a preview build uses the same database variables as production.
  • Do not update docs for behavior that has not been committed, pushed, and deployed to the relevant environment.
Last updated on