Dev environments

Separate the destination from the code

The local environment writes to academy.duckdb; dev writes the same table names to academy-dev.duckdb. The code stays the same while the database file changes. This keeps experiments away from the normal output.

The database should use read-only production credentials and allow only the tables an agent needs. A rule in a Markdown file is advice, not a technical block. bruin data-diff compares two named connections in the dev environment, but comparison does not control access.

Your task

Run the full pipeline with:

bruin run --environment dev pipeline

The command exits non-zero because the intentional mart.churn_risk check still fails; that is expected when every other asset succeeds. Then add config.full_refresh_restricted: true under the dev environment in .bruin.yml, rerun with bruin run --environment dev --full-refresh pipeline, and record the restriction warning. Use this read-only comparison plan:

bruin data-diff --environment dev duckdb-prod:weekly_category_revenue duckdb-default:weekly_category_revenue

Record the destination names and results in docs/dev-run.md. Do not write to the default environment during this task.

Check your understanding

• What does selecting dev change in this project?
• How do you select the dev environment?
• Where should the strongest write boundary live?

Do it with your agent

Say next lesson, run the isolated experiment, record the evidence, then say review my work.

Rubric

• Completes every non-broken asset in the isolated dev database and attributes the non-zero exit only to mart.churn_risk.
• Records the dev database path and demonstrates that default output was not modified.
• Adds and verifies config.full_refresh_restricted: true in dev, including the full-refresh warning.
• Describes the read-only two-connection bruin data-diff comparison and explains expected differences.