The development cycle¶
Edit a working definition, check it, inspect the Build preview, install the change, catch up data and validate the result. Use the same configuration throughout so each report describes the estate you changed.
Keep the project and configuration you just inspected. The leading commands continue Landing → Operations with workspace-development.yml, as selected on the mapping and Health pages. Edit a Landing declaration while leaving its logical names and Operations connection intact. Use the connection task if those items are not yet installed.
For another source-data estate, select its actual changed items in the same loop. A Warehouse-only reader can use --item Warehouse/Operations with the StatusEvent project. If you have added the native Parcel model and managed-source models to this project, use the model-inclusive loop below.
Edit and iterate¶
After editing the source, check it locally and preview the intended installed change:
weaver check
weaver build --item Lakehouse/Landing --item Warehouse/Operations --dry-run --workspace-config workspace-development.yml
Check catches declaration errors without contacting Fabric. Build preview reads existing targets and shows selected work and destructive consequences without changing the estate. Use ordinary Build for first deployment; previews require existing targets.
If the preview is the intended change, install and operate that selection:
weaver build --item Lakehouse/Landing --item Warehouse/Operations --workspace-config workspace-development.yml
weaver load --stale --workspace-config workspace-development.yml
weaver test --workspace-config workspace-development.yml
weaver health --workspace-config workspace-development.yml
Build reconciles source against installed state, including changed definitions and affected descendants inside its selected items. Changed loadable work begins with non-Green current state. load --stale selects installed loadables needing work; it leaves omitted Green producers alone. Test runs installed validations, then Health shows Load, Tests and Build together.
Load and catalogue-mode Test use installed definitions, not your edited source files. A data-only source change needs Load, not another Build; a declaration change must cross Build first. Source/file Tests are an alternative authoring check and do not write installed Test history.
Use an item-wide run by default. Plain named Load does not add or order dependencies. Run part of an estate teaches deliberate seed expansion and a preview when item-wide work is too broad. Completed work is not rolled back after a later failure; follow Recovery against the state that remains.
Include semantic models and Reports¶
For the managed-source Parcel extension, retain the working Landing/Operations pipelines, the native inline Parcel model and its linked Report, and the separate ParcelWarehouse model that reads Operations Parcel.CurrentStatus. Keep workspace-development.yml with the additional model and Report targets described in workspace mappings. Source-backed Import refresh requires an existing supported SQL connection.
Build source-data definitions first, then changed model/Report definitions separately:
weaver check
weaver build --item Lakehouse/Landing --item Warehouse/Operations --dry-run --workspace-config workspace-development.yml
weaver build --item Lakehouse/Landing --item Warehouse/Operations --workspace-config workspace-development.yml
weaver build --item PowerBI/Parcel --dry-run --workspace-config workspace-development.yml
weaver build --item PowerBI/Parcel --bind-data-sources --workspace-config workspace-development.yml
weaver load --stale --workspace-config workspace-development.yml
weaver test --workspace-config workspace-development.yml
weaver health --workspace-config workspace-development.yml
This iteration loop assumes the model and Report targets have already been deployed; a Build preview does not provision missing Power BI items. The PowerBI/Parcel selection covers the inline model and linked Report alongside the additional source-backed models. Preview each changed Build before applying it. --bind-data-sources requests binding to an existing connection; it does not create credentials. Estate Load coordinates selected source work and model refreshes; a source change can make the dependent model stale even if its definition is unchanged. DAX validations are part of Test. Reports have only a Build/deployment lifecycle, not Load or Test. Inspect their actual binding and rendering through the Report task.
Optional: establish a mirrored development baseline¶
Once the ordinary loop works, develop using Mirror if development should borrow existing source data rather than load every unchanged object locally. It requires existing source and destination items in the same workspace and empties the destination catalogue plus selected targets. Re-mirror only for a fresh baseline, not for each edit.
Run, test and inspect the estate is the installed-state path when no source change needs Build. Build, Load and Test explains the operation boundaries behind both paths.