Skip to main content

Documentation index: llms.txt. This page is also available as markdown: append .md to this URL or send Accept: text/markdown.

Coalesce Best Practices

This page summarizes best practices for working with Coalesce Transform. For initial setup, see the Transform Onboarding Guide. For step-by-step configuration, see Setup and Configuration.

Version Control​

Git Commits​

  • Make frequent commits with meaningful commit descriptions.
  • Keep each commit focused on a single unit of work.
  • Communicate with your team before committing to ensure the Workspace is in a commit-ready state.
  • Designate a single developer to commit to the main branch to avoid conflicts.
  • Avoid making breaking commits directly to the main branch.
Having Trouble Making Commits

If you cannot commit your changes in a Workspace to Git, contact Coalesce support. Overwriting live metadata with a previous commit can cause you to lose recent uncommitted development.

Git Branches​

  • Follow a branching strategy (for example, feature branches for development).
  • Use branches to keep in-progress work separate from the main branch.
  • Deploy to target Environments only from the main branch.
  • Only one person should work on a given branch at a time.

Git Pitfalls to Avoid​

  • Never develop directly in your main development Workspace.
  • Never merge into a Workspace that has uncommitted changes.
  • Only open one instance of the Git modal per Workspace at a time.
  • Do not change Git repository settings while there are uncommitted changes in any Workspace.

See Git Integration and Version Control Best Practices for details.

Workspaces​

Workspace Strategies​

Choose a strategy that fits your team size and workflow:

  • One Workspace per branch: Create a new Workspace for each feature branch; delete when merged. Keeps work isolated.
  • One Workspace per user: Each developer has their own Workspace and manages branches from it. Good for smaller teams.
  • One Workspace per feature: Separate Workspaces for distinct features. Reduces conflicts.

Workspace Guidelines​

  • Workspaces should map to different schemas, except for source Nodes.
  • When feature development in a Workspace is complete, merge into the main branch.
  • Check out the main branch in the Main Workspace when preparing for deployment.
  • Deploy to higher Environments (Production, QA, Testing) only from the main branch in the Main Workspace.

See Workspaces for full details.

Environment Management​

  • Each Environment should map to a different database and schema.
  • You cannot have a Workspace and Environment share the same schemas unless the Workspace is used read-only.
  • Create Environments for DEV, QA, and Production matching your Storage Mappings.
  • As a feature flows from development to Test, QA, and Production, Storage Mappings should point to the correct locations.
  • Each Environment needs its own authentication to your data platform.

See Environments and Create Your Environments for setup.

Deployment​

  • Commit work to the branch intended for deployment before deploying.
  • Configure target databases and schemas in your data platform before deployment.
  • Configure Parameters for environment-specific values.
  • Test in lower Environments (DEV, QA) before deploying to Production.
  • Decide whether to deploy using the CLI or Coalesce App based on your workflow.

See Deployment Overview for details.

Refresh and Jobs​

See Refresh Your Pipeline and Scheduling Jobs for details.

Platform-Specific Notes​

Snowflake​

  • Set source tables to READ (data read by Coalesce).
  • Set targets to READ/WRITE (where Coalesce writes transformed data).

Databricks​

Pipeline Design​

Coalesce recommends using pipelines instead of Common Table Expressions (CTEs) for complex data processing in an analytical environment. For a comparison and rationale, see CTEs vs Pipelines for Complex Data Processing.

CTEs are supported when needed. See the Coalesce documentation for how to use them.

What's Next?​