Jakie są skuteczne sposoby radzenia sobie ze schematami baz danych współdzielonymi między gałęziami kodu?

Praca nad projektem z wieloma gałęziami, w którym każda gałąź jest ostatecznie łączona z powrotem z główną gałęzią i zasadniczo jest izolowana w celu opracowania nowej funkcji.

Baza danych, którą jest MS SQL Server, ma wspólny schemat, jednak każda gałąź wprowadza zmiany do schematu w miarę jego rozwoju.

Moje podstawowe pytanie dotyczy tego, jakie są dobre sposoby radzenia sobie z udostępnianiem schematu od gałęzi głównej do gałęzi pochodnej, tak że zmiany dokonane w gałęzi głównej można łatwo scalić z gałęzią pochodną, ​​bez konieczności wprowadzania nowych zmian w gałęzi pochodnej gałąź?

Z powodzeniem zastosowałem następującą metodologię, opracowaną w Kontroli wersji i Twojej bazie danych :

• zachowaj numer wersji w metadanych (korzystam z rozszerzonej właściwości bazy danych)
• każda zmiana schematu jest kodowana jako skrypt, który aktualizuje się z bieżącej wersji do następnej wersji
• aplikacja jest dostarczana ze wszystkimi skryptami do aktualizacji z wersji 0 (wstępne wdrożenie) aż do bieżącej wersji
• Każda zmiana odbywa się za pomocą skryptu. W tym zmiany danych „systemowych”, takich jak słowniki i wpisy w tablicy odnośników.
• po wdrożeniu aplikacja sprawdza wersję schematu na dysku, a następnie uruchamia wszystkie kroki aktualizacji, aby doprowadzić schemat do bieżącej wymaganej wersji

Często słyszę opinię „czym to się różni od zwykłego trzymania skryptów definicji obiektów pod kontrolą źródła?”. Różnica jest ogromna, ponieważ podczas wdrażania nowej wersji aplikacji nie będziesz po prostu tworzyć nowej bazy danych. Najczęściej aplikacja będzie musiała zaktualizować istniejącą bazę danych, w tym istniejące dane . Jest to zasadnicza różnica, ponieważ kroki aktualizacji muszą zapewnić integralność i spójność istniejących danych podczas aktualizacji. Niektóre operacje są trywialne w kodzie (dodaj kolumnę niepozwalającą wartości zerowej z wartością domyślną do skryptu definicji obiektu tabeli, gotowe), ale w rzeczywistości są bardzo bolesne przy rzeczywistym wdrożeniu (tabela ma 1,5 miliarda wierszy, kolumna dodania skończyłaby się miejsca w dzienniku, jeśli wykonano to w sposób „uproszczony”).

Jak to działa z rozgałęzianiem:

• kiedy gałąź jest tworzona, przyciąga bieżącą wersję schematu, powiedzmy wersja 1.6
• gdy zespół rozpoczyna pracę nad gałęzią, dodaje nową wersję, 1.7, a następnie zaczyna kodować etap aktualizacji z 1.6 do 1.7
• krok aktualizacji zostaje zmieniony w miarę dokonywania modyfikacji w oddziale. Zawsze uruchamia skrypt aktualizujący się z wersji 1.6 do 1.7, ale to, co dokładnie robią te skrypty, podlega normalnym iteracjom kodu i meldowaniu w gałęzi
• oddział kończy rozwój, przygotowuje się do odwrotnej integracji (do połączenia z powrotem w linię bazową)
  • dokonuje nowej integracji do przodu od linii podstawowej do gałęzi. Jeśli integracja nie przyniesie żadnych zmian w wersji schematu, wszystko jest w porządku, gałąź może odwrócić integrację bez zmian. wersja 1.7 staje się nową wersją bazową.
  • ciekawe jest to, że w międzyczasie inna gałąź zintegrowała się odwrotnie z bazą, a teraz wersja podstawowego schematu zmieniła się, powiedzmy, na 1.7. W takim przypadku nasz oddział musi podnieść wersję docelowego schematu wdrażania do wersji 1.8 i dokonać przeglądu kroku aktualizacji, który poprzednio był z wersji 1.6 do 1.7, aby zobaczyć, jak działa w nowym środowisku, aktualizując z wersji 1.7 do 1.8. Logiczne konflikty schematów muszą zostać rozwiązane, skrypt może wymagać zmian, testy muszą zostać wykonane. Po zakończeniu gałąź może odwrócić integrację z bazą. Wdrożona docelowa wersja produktu staje się teraz 1.8.
  • kiedy inna gałąź, która rozwidliła się w schemacie w wersji 1.6, chce przeprowadzić integrację wsteczną, będzie musiała podbić swoją wersję schematu do wersji 1.9, przetestuj skrypt aktualizacji z wersji 1.8 do 1.9, a następnie może ponownie zintegrować się z bazą.

Zauważ, że nie jest w to zaangażowane żadne narzędzie, nie ma skryptu magicznego schematu różnicowego, nie ma żadnych kreatorów ani żadnego skryptu generującego kliknięcie prawym przyciskiem myszy. Jest to proces w 100% sterowany przez programistów, oparty na źródłach (skryptach). Wielu uważa, że ​​cały proces jest skomplikowany, ale działa. W rzeczywistości, jako użytkownik programu SQL Server, wykorzystałeś już wyniki tego procesu w codziennym korzystaniu z programu SQL Server: sam program SQL Server korzysta z bardzo podobnego procesu aktualizacji bazy danych i, jak można się spodziewać, proces rozwoju produktu ma szerokie zastosowanie rozgałęzień, a wspomniany problem jest bardzo realnym problemem, który należy rozwiązać.

BTW, sposób, w jaki faktycznie zachodzi rozgałęzienie / integracja, różni się w zależności od produktów kontroli źródła, używam terminów znanych z trybu działania integracji z perforacją .

Chociaż moja odpowiedź może nie być tak długa jak odpowiedź Remusa, uznałem, że jest to naprawdę dobre rozwiązanie. Nie mam go jeszcze w produkcji, więc YMMV *.

Liquibase

Zasadniczo jest to plik XML, w którym wprowadza się zmiany schematu w bazie danych jako nowe elementy w pliku XML. Na przykład:

<createTable tableName="department">
            <column name="id" type="int">
                <constraints primaryKey="true" nullable="false"/>
            </column>

Ma w pełni rozwiniętą składnię, dzięki czemu możesz praktycznie zrobić dowolną bazę danych.

W instalacji Liquibase określasz również, która baza danych ma być wersjonowana. Następnie „uruchom” plik .xml za pomocą dołączonego pliku wykonywalnego Java (plik jar). To w zasadzie odtwarza te zmiany określone w pliku XML w bazie danych.

Prawdziwym kickerem jest to, że przechowujesz ten plik XML w tym samym wersjonowanym folderze co kod. Więc w moim przypadku był to Git. Miałem ten plik XML w folderze projektu (na tym samym poziomie co /.git), a następnie za każdym razem, gdy przełączałem gałęzie, plik XML zmieniał się na tę wersję gałęzi i uruchamiałem plik .jar, a moja baza danych odzwierciedlała teraz tę gałąź.

* Uwaga: Nie ukończyłem implementacji, ponieważ miałem problemy z podłączeniem Javy do SQL Server. Potrzebuje sterowników jdbc itp. I nie byłem w nastroju. W związku z tym przebieg może się różnić.

Tutaj w Red Gate wkrótce wypuszczamy rozwiązanie do wersjonowania baz danych, które wykorzystuje zarówno SQL Compare, jak i SQL Source Control. Wykorzystuje to podejście do aktualizacji skryptów migracyjnych i stempluje bazę danych właściwością rozszerzoną do wersji, która odpowiada rewizji kontroli źródła.

Mamy nadzieję na wydanie w połowie grudnia. Dostępny jest teraz kandydat do wydania. Po więcej informacji odwiedź:

http://www.red-gate.com/products/sql-development/sql-source-control/entrypage/migration

Mamy nadzieję, że w nadchodzących miesiącach będziemy korzystać z tego rozwiązania, więc daj nam znać, co myślisz.

Jeśli Ty i zajmujesz się zmianami schematu poprzez generowanie skryptów i utrzymywanie tych skryptów pod kontrolą źródła, powinieneś być w stanie traktować zmiany jak w przypadku każdego innego scalenia kodu. Możesz wybrać automatyczne scalanie lub podjąć więcej ręcznej interwencji.

Jestem w podobnej sytuacji, gdy pracuję na działającej stronie internetowej i kilku gałęziach programistycznych, w których muszę zmienić schemat bazy danych.

Rozwiązałem to, pisząc po kasie i haku po scaleniu, które można ładnie używać z git. Wszystkie moje migracje przechowuję w postaci plików SQL w osobnym katalogu i zatwierdzam je wraz ze zmienionym kodem PHP. Za każdym razem wykonuję

git checkout

lub a

git merge

git automatycznie wywoła odpowiednie migracje w górę i w dół. Zobacz moją implementację na Github .