Branching & CI
Learn Foundry's Git-based branching model and how continuous integration ensures quality before merging.
1 · Branch-Based Development
Every Code Repository in Foundry uses Git branches. When you want to make a change, you create a branch, modify your transforms, and preview the results — all without touching production data.
Datasets on a branch are isolated: building on your branch creates branch-specific dataset transactions. Other users continue to see the production (main-branch) data until you merge.
2 · Continuous Integration Checks
When you open a merge request (Foundry's equivalent of a pull request), CI checks run automatically:
- Schema validation — do output schemas still match?
- Expectation checks — do data quality rules pass?
- Dependency analysis — are all inputs available?
- Code quality — linting and type checks.
Only when all checks pass can the branch be merged, protecting production quality.
3 · Merge Strategies
After merging, Foundry offers two strategies for updating downstream datasets:
1. Build on merge — immediately rebuild affected outputs.
2. Build on schedule — wait for the next scheduled build.
For critical pipelines, build-on-merge ensures consumers get updated data as fast as possible. For less time-sensitive flows, scheduled builds reduce compute costs.
✅ Key Takeaways
- Branches isolate changes — your experiments never affect production data.
- CI checks run automatically on every merge request.
- Schema validation, expectations, and dependency analysis protect quality.
- Build-on-merge or build-on-schedule strategies control when updates propagate.