Skip to main content

Deployment Overview

Deployment creates the structural foundation of your Pipeline. When you deploy, Coalesce analyzes the differences between your current Environment and your desired configuration, then executes the necessary changes.

Once you've completed Setting Up Your Project and Building Your Pipeline, you're ready to deploy your Pipeline to your data warehouse.

Governance and Production Deployments​

Production deployments stay predictable when you combine controls from version control, your continuous integration and delivery automation, and Coalesce. This section describes how those layers fit together, how manual and automated promotion work, and where to look when something blocks a deploy.

Where Governance Lives​

Governance is shared across three areas. You configure each one in its own system:

  • Version control - Required reviewers, protected branches, optional merge queues, and repository rules live here.
  • Continuous integration and delivery - Workflow triggers, job approvals, secret storage, and optional checks before a deploy runs are defined in your pipelines.
  • Coalesce - Each Environment maps to branch and commit selection at deploy time, and RBAC Roles and Permissions control who can run deploys through the Coalesce App, API, or Deploy Using the CLI. Deploying requires Environment Admin on the target Environment.

Together, these layers decide which commits are eligible to run against which warehouse credentials, and who can start that work in Coalesce.

Branches, Commits, and Non-Development Environments​

Coalesce applies the branch and commit you select when you deploy. For non-development Environments, align with the DataOps pattern of treating one integration branch, often main, as the source of truth for promoted work. That keeps Workspace development flexible while production-like Environments track a single, reviewed line of history.

Environment mapping and branch discipline are covered in more detail in DataOps Best Practices with Git and Coalesce.

Pull requests and deploys

Pull request review is enforced by your Git host as part of merging into protected branches. It is not a substitute for Coalesce roles: an approved merge still requires an account with Environment Admin or an automated principal with that role to deploy to the Environment. Coalesce does not add a second pull request approval step on the deploy action itself.

Manual Promotion in the Coalesce App​

Use this pattern when a person promotes vetted commits after merges complete.

  1. Confirm the commit you want is on the branch your team uses for production metadata, often main.
  2. In the Coalesce App, open Deploy for the target Environment. An Environment Admin starts the Deploy Wizard.
  3. On Select Commit, pick that branch and commit.
  4. On Review Plan, inspect DDL and warnings, then finish the deploy.

Step-by-step UI detail is in Deploy Using the Coalesce App.

Automated Promotion in Pipelines​

Use this pattern when merges or tags should trigger coa plan and coa deploy without someone clicking through the wizard.

  1. Store the Coalesce API token and related secrets in your CI system, not in the repository.
  2. Run coa plan, review or archive the plan artifact as your team requires, then run coa deploy with that plan against the target Environment.
  3. Give the identity your pipeline uses Environment Admin on the Environment it deploys to. Many teams use a dedicated Environment for automation so production credentials stay behind a separate manual or gated job.

Command reference is in Deploy Using the CLI. A full GitHub Actions example is in Orchestrate Deploys With GitHub Actions and the CLI.

For Git operations inside automation when a bot performs commits, clones, or pushes, use a dedicated Git account so tokens and ownership do not depend on an individual developer. See Creating a Git Service Account. For the Coalesce side of automation identities, see Service Accounts in Coalesce.

Example Team Patterns​

These patterns are simplified sketches you can adapt to your own naming and Environment layout.

Small Team: Merge in Git, Then Deploy From main​

Your Git host requires at least one approving review before merge into main. After the merge lands, an Environment Admin opens the Deploy Wizard for Production, selects main and the new commit, reviews the plan, and deploys. Lower Environments can follow the same branch or use feature branches for testing before you merge.

Larger Team: Protected main, Automation to a CI Environment, Optional Human Gate for Production​

main stays protected with required reviewers in GitHub or your equivalent Git host, with an optional merge queue if your team uses that feature. A workflow on push to main runs coa plan and coa deploy into a dedicated CI or staging Environment using a service identity with Environment Admin on that Environment only. If you want an extra human checkpoint before Production, keep Production deploys as a separate manual Deploy Wizard step or a workflow that runs only after an allowed approver starts it in your CI system.

Automation Accounts for Git and Coalesce​

A pipeline bot or service user performs Git steps and calls Coalesce with an API token. Configure that Coalesce identity using Service Accounts in Coalesce so it has Environment Admin on the automation Environment, following Adding Users and Setting Permissions. Pair it with Creating a Git Service Account so Git credentials match the automation story.

Hotfixes on a Faster Path Than the Normal Release​

When you cannot wait for the standard release cadence, you still branch, test, and merge in Git before Production sees the commit. Branch from your integration branch, implement the fix, validate in a lower Environment, deploy where needed, then merge back so main stays authoritative. Follow the numbered hotfix flow in Hotfix Management in the DataOps guide.

Optional Policy Checks in Pipelines​

Some organizations add static analysis, policy engines such as Open Policy Agent, or custom gates so a job fails before coa deploy runs. Those checks are part of your pipeline definitions and tooling choices, not built-in Coalesce product rules. Design them where you already enforce repository and infrastructure standards.

When Automated Deploys Fail With Permission Errors​

If coa deploy from CI reports permission or env-deploy style errors, treat it as a roles and secrets problem first. Confirm the Coalesce identity has Environment Admin on the target Environment and that your secrets match the Environment and Project you intend. Walk through COA Deployment Error Resolution and confirm data platform grants for the Environment credentials.

Deployment Methods​

You can deploy your Pipeline using:

Before You Deploy​

This assumes you've created your Pipeline. If you don't have one, check out the Quick Start Guide.