Datenbankänderungen und pull requests (git)



  • Hallo.

    Ich habe da mal eine Verständnissfrage.

    Wenn man mit Git arbeitet, dann erstellt sich jeder Entwickler Branches in die er seine Arbeit commited. Ist er dann irgendwann fertig, dann erstellt er einen pull request den andere Entwickler akzeptieren müssen usw.

    Während der Entwicklungszeit am Branche wird in der Regel von anderen Entwicklern am Head weitergearbeitet. Dh es kann sich auch etwas an der Datenbank der Anwendung ändern. Diese Änderungen an der Datenbank können theoretisch auch dazu führen, dass ältere Versionen nicht mehr funktionieren oder eben auch Branches auf der Datenbank des Heads nicht mehr funktionieren.

    Wie funktioniert dann eigentlich dieses testen/prüfen des pull requests durch andere Entwickler. Wird normalerweise für jeden Branch auch gleich ein Datenbankbackup gemacht auf dem man diesen Branch dann testen/prüfen kann?
    Das wäre doch ein enormer Aufwand, weil man das theoretisch für jeden Branch machen muss.
    Gibt es hier eventuell Tools die Datenbanken ähnlich versionieren wie Git das mit Code macht.

    Konstruiert ist dieses Problem/Frage denke ich nicht, allerdings stelle ich mir die Lösung dafür extrem aufwendig/speicherplatzintensiv vor und deshalb kaum praktikabel. Wie sieht das also in der Realität/Praxis aus?



  • Database Migrations.

    Dein System sollte sowieso die Möglichkeit haben Migrationen zu machen, wie passt man sonst eine DB an wenn man ein Update einspielt?

    Schau dir uU mal Flyway an.



  • Danke erstmal für die Antwort.

    Geht hier eher um das Verständniss wie man arbeitet.

    Migration von Datenbank ist denke ich klar. Man wird normalerweise irgendwelche Möglichkeiten haben die Datenbank anzupassen also irgendwas hinzufügen/entfernen. Aber das ist doch normalerweise nur der Weg in eine Richtung (zur nächst höheren Version). In der Regel wird man doch nichts abwärts migrieren oder das zuminderst nicht standardmäßig entwickeln.
    Also man wird irgendetwas entwicklen/schreiben, damit eine Spalte hinzugefügt wird. Aber man wird doch nicht (per default) gleichzeitig etwas entwicklen/schreiben, dass diese Spalte wieder entfernt oder?

    Microsoft bietet mir afaik auch nicht die Möglichkeit von Windows 8 wieder auf Windows 7 zurück zu gehen. Dazu muss ich dann Windows 7 neu installieren.

    Bin mir nicht sicher ob ich flyway richtig verstehe, habs mir jetzt auch nur mal eben 2 Minuten angeschaut. Wenn ich jetzt zB sage migirere mir auf Version 47, kann ich dann auch später wieder sagen geh zurück auf Version 40?
    Theoretisch müsste das machbar sein, weil die einzelnen "Zustände" werden offensichtlich versioniert. Aber ich stelle es mir jetzt nicht unbedingt trivial vor dann auch einfach wieder auf eine frühere Version zurück zu gehen.

    Aber danke erstmal, ich werd mir das mal genauer anschauen.



  • git schrieb:

    Aber man wird doch nicht (per default) gleichzeitig etwas entwicklen/schreiben, dass diese Spalte wieder entfernt oder?

    Prinzipiell sind Downgrades meistens nicht notwendig.

    Aber wenn du einen feature branch hast, der auf der DB etwas ändert, dann haust du eine entsprechende Migrationsstufe rein. Wenn du dann pullst und jemand anderer hat bereits etwas geändert, dann hast du einen merge conflict den du händisch lösen musst (uU kann dein db migration system das ja eh automatisch) und du spulst deine lokale DB auf den stand vom master. Und dann passt du deine migrations routine an.

    Also zurück gehen ist uU möglich, je nach system aber idR nicht notwendig. Wieso willst du aber downgraden? Entwicklung ist immer upgrading.

    Du hast eine lokale upgrade routine und jemand anderer pusht eine upgrade routine -> merge conflict. So einfach.

    PS:
    wenn du denkst dass du von deinem branch erstmal downgraden musst, bedenke dass du auch einfach von 0 auf master upgraden kannst.



  • Das Thema ist hier nicht so sehr Code und Entwicklung sondern eher Datenbank und testen/prüfen.

    Entwickler A entwicklet das feature im Branche
    Entwickler B entwicklet den Head weiter und macht entsprechend seine Datenbanekänderungen auf seiner Datenbank

    Jetzt ist Entwikcler A fertig und erstellt seinen pull request (merge kommt erst nach freigabe des pull requests)
    Entwickler B soll/muss jetzt auf seiner Datenbank im Stand "Head" das feature von Entwickler A mit Datenbankstand "Branch" testen bzw den pull request freigeben. Wie kommt Entwickler B also jetzt zu einer Datenbank "Branch".
    Klar könnte man beim ertellen eines Branches ein Datenbankbackup machen oder wenn man den pull request erstellt eine passende Datenbank hinterlegen. Nur sind das doch keine praktikablen Wege (Speicherplatz, Aufwand, usw.)

    btw wie entscheide ich den, ob eine weitere Migration der Datenbank überhaupt ein Mergekonflikt ist. Wenn das feature von Entwickler A nur Tabelle A benötigt und alle Migrationen im Head nur auf Tabelle X, Y und Z gehen, dann ist mir das doch egal. Dann funktioniert auch die Datenbank des Head mit dem Code aus dem Branche.

    Entwickler A könnte natürlich auch einen "rebase?" (ich glaube das heißt so, also den Branch auf den Head hochziehen) machen, dann müsste auch der Zustand der Datenbank wieder identisch sein.
    Rebase kommt aber meinem Verständniss nach erst nach genehmigtem pull request?

    Von 0 wäre natürlich auch eine Idee. Dann habe ich aber auch immer eine leere Datenbank zum testen, was vermutlich auch nicht ideal ist. Man will beim testen vermutlich schon "lebendige" Daten haben.

    Ich denke ein Git für die Datenbank wäre schon gut, also dieses flyway. Das clean und baseline müsste vermutlich das sein was man da braucht oder verwenden kann.



  • git schrieb:

    Jetzt ist Entwikcler A fertig und erstellt seinen pull request (merge kommt erst nach freigabe des pull requests)

    Bevor du pull request stellst einfach rebase auf master machen.
    Wieso solltest du nach dem aktzeptierten request rebasen? Das bringt dir ja nichts mehr, da dein Branch dann ja eh zu ende ist und eigentlich weggeschmissen werden kann.

    Immer zuerst rebasen bevor man pusht/pull requestet.

    PS:
    Durch das rebase liegt der merge conflict bei dem der denn pull request erstellen will - und dort soll er ja auch behandelt werden. Das feature soll ja auf dem master basieren und nicht auf einer alten Version von vor 3 jahren.

    Deshalb will man idR öfters rebasen wenn man länger an dem branch arbeitet.



  • Das mit dem rebase ist halt auch so eines meiner Probleme. Den sinn eines rebase verstehe ich nicht ganz (in kombination mit pull requests). Woher soll ich den wissen, wann der Reviewer meinen pull request anschaut. Wenn da wieder x Tage/Wochen dazwischen liegen habe ich doch das gleiche Problem wieder.



  • git schrieb:

    Das mit dem rebase ist halt auch so eines meiner Probleme. Den sinn eines rebase verstehe ich nicht ganz (in kombination mit pull requests). Woher soll ich den wissen, wann der Reviewer meinen pull request anschaut. Wenn da wieder x Tage/Wochen dazwischen liegen habe ich doch das gleiche Problem wieder.

    Tja, dann muss man nochmal rebasen wenn der pull request zu alt ist.

    Prinzipiell ist ein pull request nichts anderes als zu sagen "ich bin fertig". Wenn der master weiter wandert, dann muss man eben den pullrequest zurück ziehen, rebasen, neu requesten.
    Oder der maintainer rebased selber neu. Das ist aber ja kein technisches Problem.

    Ein rebase sagt, dass dein branch wieder auf dem stand vom master ist. Ein feature branch sollte immer auf einem relativ aktuellen master basieren. Man muss nicht alle 5 minuten rebasen, aber regelmäßiges rebasen ist wichtig, schließlich muss das feature ja mit dem aktuellen master funktionieren und nicht mit dem master vom letzten jahr.

    Wenn pull requests jahrelang rumliegen führt das natürlich zu problemen. Aber wenn der master die DB geändert hat dann musst du ja testen ob dein feature jetzt noch korrekt funktioniert: also musst du rebasen und testen.


Log in to reply