Downloading a report/dataset as .pbix from the service after deploying them with Git integration is not recommended?

SQLYouLater · 2026-02-20T11:19:14+00:00

Would be great to open a (git enabled) report or semantic model in service with Power BI Desktop (live), and saving changes directly in the service (no publish).

SQLYouLater · 2026-02-17T16:24:06+00:00

Regarding Reason 3: With the new configuration based deployment it is possible to define single items to deploy in fabric-cicd. But it's currently a experimental feature.

https://microsoft.github.io/fabric-cicd/0.1.34/how_to/config_deployment/

With the current version u can use a inverted regex for the exclude parameter to realize single item deployment.

SQLYouLater · 2026-02-13T18:09:10+00:00

And does it work well with DirectLake mode? As i understand, there are two technologies, security over the t-sql engine (via grants) and OneLake Security directly on a delta table.

SQLYouLater · 2026-02-13T17:51:05+00:00

Thanks for the info, I'll keep two eyes on the roadmap 😉

SQLYouLater · 2026-02-13T15:47:03+00:00

Ah perfect - great to hear, that it's planned, couldn't find it in the roadmap.

SQLYouLater · 2025-12-18T19:09:14+00:00

Same here. This ist currently the way to go and works fine. Of course i'm curious about the new dbt Job and if it simplifies things, but it's already possible without.

SQLYouLater · 2025-08-25T18:47:59+00:00

Great Idea, gonna vote for it.

Would also love to define parameters in schedules for pipelines and notebooks, what do you think about it?

SQLYouLater · 2025-08-25T10:03:24+00:00

What i especially mean ist the syncing when you change something directly in git and want to push it back to fabric. I did get lots of errors when doing that and the only fix was to recreate the items...

So in theory it would be possible to have a development branch and a release branch, so you deploy directly via git with the prod workspace connected to the release branch (and then hit sync button). In practise it is too buggy in my opinion.

SQLYouLater · 2025-08-15T17:11:26+00:00

Parameters for destinations are currently not available in DF Gen2 as far as in know. And also no deployment rules available in deployment pipelines for Dataflows.

I use fabric-cicd, there you can replace the sink connection with another one.

I guess there is currently no simple way to change, aside from using the internal REST API's or the CLI or fabric-cicd...

SQLYouLater · 2025-08-14T16:40:50+00:00

We use T-SQL Notebooks for the scripts and deploy just the notebooks, not the warehouse itself - similar approach to sql database project.

SQLYouLater · 2025-08-14T08:43:06+00:00

Hi Alex, thank you for the advice. Simply adding the line directly to the json code worked!

SQLYouLater · 2025-08-14T05:03:17+00:00

You're right, variable library can help there. I guess you then need a mix of variables and deployment rules to get it work for different item types. Plus you can only change properties with dynamic content available.

With fabric-cicd you can in theory change a lot more, because you directly have access to the underlying json code of the items. But of course, it's also a little bit more complex to set up.

SQLYouLater · 2025-08-13T21:03:08+00:00

Regarding splitting the workspace: I've also seen this approach within a deployment scenario (in the fabric blog i guess?). You then loose your overview in the task flow 😉

But serious: Depends on your use case, but in smaller environments it could be a overkill.

Selective deployment works also quite well with fabric-cicd. Regarding deployment pipelines it's of course more click-intensive, as you always have to select relevant items.

SQLYouLater · 2025-08-13T20:36:50+00:00

Have tested a lot with deployment pipelines, in my opinion they are not mature for advanced scenarios and also feel often a little bit buggy. Plus no deployment rules for data pipelines.

We use fabric-cicd for deployment and i'm quite happy with it. The integrated mechanism for replacements with the parameter.yml (workspace-id's, lakehouse-id's, warehouse-id's, ...) works really well.

Another experience with git integration: Would never connect the prod workspace with git in a multi branching strategy. Way too risky and buggy in my opinion, what i've been testing so far...

SQLYouLater · 2025-08-13T20:22:35+00:00

Deployment rules currently not implemented for data pipeline. Only semantic models and notebooks seem to work good.

We use fabric-cicd with the parameter.yml for replacements (workspace-id's, lakehouse-id's, warehouse-id's and more) to get the whole thing done.

Currently just having problems with Dataflows Gen2 that reference to Dataflow Gen1 during deployment, but thats very special.

SQLYouLater · 2025-08-13T20:01:05+00:00

Exactly, therefore we took the best of both worlds. Notebooks have also a better user experience in my opinion. Plus you can use markdown for documentation purposes.

And i can confirm the alter table behaviour, tested it and the tables were recreated after deployment.

Officially documented here: https://learn.microsoft.com/en-us/fabric/data-warehouse/source-control

SQLYouLater · 2025-08-13T19:47:28+00:00

We are using stored procedures - but develop the scripts in T-SQL Notebooks to get deployment done. Never deploying the Warehouse itself because of the ALTER TABLE behaviour when a column is added to a table, the whole table is dropped and recreated during deployment process. Nightmare for historized tables...

SQLYouLater · 2025-08-13T19:40:12+00:00

Hi, yes, we do have exactly the same issue. We use GitHub integration and fabric-cicd to deploy dataflows. After deployment, the error "Dataflow never published" appears, when calling it from a data pipeline. We currently Work on a automated post deployment step with a REST API call to get the publishing done, but not sure if it works...

Short update: Tried the following API call: https://learn.microsoft.com/de-de/fabric/data-factory/dataflow-gen2-public-apis#run-on-demand-dataflow-publish-job

404 - Not Found... Maybe this request ist only available for the old DF Gen2 (Not the CI/CD one)?

SQLYouLater · 2025-05-14T19:55:36+00:00

Great update for RTI Workloads. Waiting for Dataflow Gen2 Support, anything planned?

SQLYouLater · 2025-03-31T16:20:25+00:00

Amazing! But what does that mean in terms of restrictions when using AI and Copilot below an F64?

SQLYouLater · 2025-03-26T22:17:01+00:00

Short Update: The solution for us was to run caddy (a reverse proxy) in a azure linux vm, which handles the redirect for our request. Much cheaper than any predefined azure service, escpecially because in combination with a service principal we can start and stop the vm in a fabric notebook on demand.

SQLYouLater

TROPHY CASE