Forum Discussion
Git Branching with active Schedules
Hi Anonymous,
Haha, yes it does feel like someone has gone git happy 😄 I wish they'd focus on Lakehouse git version integration instead.
Yes, we've gone for a similar solution. In the develop branch, which is the branch we all pull from, we have the committed versions of the schedules turned off, but then turn them back on in the workspace. So unfortuantly we have to live with the uncommited icon noficiations in the workspace, which is annoying, but we can live with.
Only our Dev workspace is backed by git, the develop branch. The code is pushed into other workspaces by our DevOps deployment pipelines. Or you can use the Fabric deployment pipelines too. So turning on/off schedules in Dev workspace does not affect the test and production workspaces.
Hi Anonymous,
Thank you for sharing your experience. Yes tracking schedules in git can cause unexpected diffs in Dev/feature workspaces. The best way to avoid this is to keep schedules disabled in Dev and enable them only in Test/Prod via deployment pipelines or automation. This keeps git clean and makes sure schedules only run where they should run.
Thanks and regards,
Anjan Kumar Chippa
How can disabling the schedule in dev/feature workspaces avoid a diff when this is exactly what causes the diff in the first place?
Or are you suggesting that you keep all schedules disabled in the source code, and enable them in Test/Prod as part of the deployment process? This would also cause a diff but now its on Test/Prod instead of Dev/feature because git thinks the schedule is disabled but the workspace has it enabled?