Course overview/Foundations3 of 4

Course workflow and development environment

Back to course

Foundations - Step 3 of 14

Course workflow and development environment

Set up a local project, environment, and review loop.

Keep development separate from shared data

Work in a local project and a development environment before you change a shared table. This gives you a place to inspect the SQL, test a small date range, and review the change in version control.

The project should keep pipeline definitions, assets, checks, connection names, and documentation together. Avoid copying environment-specific values into SQL files or agent prompts.

Glossary

  • Project is the repository that contains the configuration and files for a data workflow. It gives the team one place to review a change.
  • Branch is an isolated line of Git history for a change. Use it to keep unfinished model work out of the shared branch.
  • Environment supplies values for a specific context, such as development or production. It can point the same pipeline at a different schema, connection, or set of variables.
  • Connection is a named configuration for reaching a warehouse, source, or service. Keep credentials in the configured secret provider rather than in an asset file.
  • Configuration is the project-level setup that tells Bruin where to find pipelines, connections, and environment values. Treat configuration changes with the same care as SQL changes.
  • Narrow run is a run limited to one asset, a small interval, or a selected group of assets. It reduces the time and data affected while you test a change.

A basic change process

  1. Create a branch and state the intended grain of the model.
  2. Make the smallest SQL, Python, or configuration change that tests the idea.
  3. Validate the project and render the changed asset.
  4. Run the smallest useful interval or asset selection in development.
  5. Inspect the rows and checks, then open a pull request with the model's purpose and impact.

What to record in a pull request

  • The model and the business question it supports.
  • The grain and primary key.
  • The source data or upstream models that changed.
  • The run or validation command you used.
  • Any backfill, full refresh, or downstream effect that needs review.

This process is the same in Bruin, dbt, or another transformation tool. The commands differ, but the review questions stay the same.

Sign up to our newsletter

Practical updates on open-source data pipelines, AI analysts, governance, and what we are shipping at Bruin.