Forum Discussion

caseybks's avatar
caseybks
Advocate III
11 months ago
Solved

Git Branching with active Schedules

Hi,   We are using git integration with our development environment workspace. Develop is our collaboration branch from which the data engineers create a feature branch from. Their feature branch i...
data engineering
data pipeline
  • caseybks's avatar
    caseybks
    11 months ago

    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.

Anonymous's avatar
Anonymous
Not applicable
11 months ago

scheduling in dev or test purely comes down to the SDLC process and naming conventions, I am having a similar issue though

 

I have scheduled a pipeline in my production environment, but because the schedule itself is tracked by git, it wants to enable that schedule on my dev workspace which I obviously don't want to do

 

I can disable it in the dev workspace but this is entirely manual (without adding extra steps to our devops pipelines to do this for us when dev branch is updated via PR) AND if I do this, my dev workspace now reports a diff between the workspace and git which is very annoying because future features added to dev may cause issues when calling the gitSync API endpoint in the DevOps pipeline if the workspace believes there to be a conflict

 

It fundamentally doesn't make sense to track schedules in git this way when you are not going to want every item to be scheduled in every feature, dev or test/UAT workspace, I can't think of any git based workflow that tracking if the schedule is enabled would work that doesn't cause the above issues, even the simplest trunk based workflow with feature PRs directly into main/prod would still cause either: 

 

schedules for everything enabled in every feature workspace OR

diffs reported in main/production workspace by adding schedules outside of git

 

just feels like someone has gone git-happy by adding this without actually considering the impact on different workflows

 

Also, I have added *.schedules and **.schedules to my git ignore and this doesn't prevent the workspace from reporting a diff