Forum Discussion
Difference in pipeline scheduling between DEV and PROD causes confusion during deployment
Hi Corujo ,
This is a common scenario when managing Microsoft Fabric pipelines across different environments. It’s best to handle scheduling as environment-specific, rather than embedding it in the pipeline itself. You can keep the pipeline design consistent in both DEV and PROD, but manage the schedule separately in each workspace.
For your situation, consider removing the daily schedule from the DEV pipeline and only setting it up in the PROD workspace after deployment. This keeps the pipeline design in sync across environments, with scheduling as the only difference. You can do this manually or automate it using PowerShell or the Fabric API.
Alternatively, you could create a small orchestrator pipeline in PROD to run the main pipeline on a schedule, while in DEV you run it manually for testing. If you’re using Deployment Pipelines, you can set rules to keep schedules disabled in DEV and active in PROD. In general, separating schedules from the main pipeline helps keep DEV and PROD aligned and avoids confusion during deployment.
I have several master Data Pipelines that orchestrate different isolated processes, each with its own schedule. I don’t like the idea of creating additional pipelines in production just for the purpose of scheduling the execution of these other pipelines, since they are already designed as masters themselves.
For now, I think I’ll leave it as it is: I’ll remove the schedule in DEV and enable it only in PROD, even though I don’t like seeing schema differences when deploying elements because it can be confusing.
I hope that in the future it will be possible to create deployment rules for this kind of scenario, as I believe it’s a common use case in real-world implementations. In the end, we all want to clearly understand which elements have actually changed between DEV and PROD to improve efficiency.
Hi Corujo ,
I agree, the deployment pipeline comparison in Fabric does include scheduling details such as triggers as part of the pipeline definition. That’s why you’re noticing differences between DEV (no schedule) and PROD (daily trigger). Until environment specific deployment rules are available, you might consider documenting the expected schedule differences in your deployment checklist or workspace documentation to make reviews and comparisons easier. Alternatively, you can automate trigger setup after deployment, for example, if you’re using the API or PowerShell, include a step to re-enable or update the PROD trigger once deployment is complete. This helps keep environments consistent while ensuring that the production schedule continues to run as intended.
It would also be helpful to share this feedback through Microsoft’s official feedback channels, such as Microsoft Fabric Ideas -
https://community.fabric.microsoft.com/t5/Fabric-Ideas/idb-p/fbc_ideas/ideas/search-ideas
Feedback submitted through these channels is frequently reviewed by the product teams and can contribute to meaningful improvements.
Best regards,
SreetejaHi Corujo ,
I hope the above details help you fix the issue. If you still have any questions or need more help, feel free to reach out. We’re always here to support you