Jak radzisz sobie z ciągle zmieniającymi się wymiarami bazy danych?

9

Przez ostatnie dwa miesiące szukałem rozwiązań lub praktyk do obsługi zarządzania wydaniami w bazach danych. Szukam tego, co ludzie uważają za najlepszy proces radzenia sobie z tym.

Mamy 3 środowiska dla naszych baz danych:

  • Rozwój
  • Testy akceptacji użytkownika (UAT)
  • Produkcja

Problem polega na tym, że czasami wprowadzamy zmiany do kilku rzeczy w naszej bazie danych programowania i przychodzi czas na wdrożenie, niektóre funkcje mogą nie być gotowe do wydania w UAT.

Ostatnio zaczęliśmy używać kontroli źródła SQL Red Gate do przechowywania wszystkich naszych encji (z regularnymi zatwierdzeniami).

Myślałem o wyjściu z zestawu zmian (tj. Powiedzmy, że wszystko od zestawu zmian X i wstecz jest teraz wypychane do UAT), ale oznacza to, że ludzie sprawdzają kod pod kontrolą źródła tylko przed wykonaniem wdrożenia, które może być mylące ( zwłaszcza, że ​​ludzie zapominają). Innym problemem związanym z podejściem do zestawu zmian jest to, że jeśli w procedurze przechowywanej występuje błąd, który należy naprawić, numer zestawu zmian skończyłby się poza zakresem naszego maksymalnego zestawu zmian dla wersji, dlatego też jest tak, że jeśli musimy odtworzyć bazę danych z maksymalnego zestawu zmian, ponownie wypchniemy błąd.

Wszelkie sugestie dotyczące procesu?

Dzięki

database sql sql-server tsql judda
źródło
Wygląda na to, że skrypty bazy danych nie mają tej samej kontroli źródła, co „rzeczywisty” kod. Dlaczego to? Czy możesz potraktować go jako „kod źródłowy” i umieścić go w poszczególnych gałęziach?
Mike M.
Obecnie przechowujemy tylko wersję programistyczną skryptów w kontroli źródła, a UAT / Production nie są zsynchronizowane z aktywnym programowaniem. Każdy ze skryptów w kontroli źródła jest aktualizowany za każdym razem, gdy programista dokonuje zatwierdzenia. Problem z poszczególnymi gałęziami polega na tym, że mamy 1 scentralizowaną bazę danych, z której wszyscy korzystają (w przypadku większych zmian wydzielamy osobne bazy danych).
1
Możesz utworzyć gałąź dla wydania i zatwierdzać tylko zmiany dotyczące tego wydania. Wszystkie inne zmiany należy wprowadzić do bagażnika. Aby to osiągnąć, potrzebujesz dwóch baz danych programowania. Czy to byłby problem?
To brzmi, jakby ktoś dość szybko przestał być aktualny. Nie? W przypadku jednego z moich projektów jesteśmy w trakcie gruntownego przeglądu bazy danych, więc wykonaliśmy rozgałęzienie, aby nadal możliwe było aktywne opracowywanie niezmodyfikowanej wersji bazy danych. Jednak każdego dnia widzę, że nasza wersja rozgałęziona staje się coraz bardziej nieaktualna, co nie jest pewne, czy to jest w porządku, czy nie ... Nigdy tak naprawdę nie miałem do czynienia z takimi sytuacjami jak wcześniej.
judda

Odpowiedzi:

5

Migracje

W górę i w dół, które są w twoim repozytorium i oznaczone wraz z aplikacją.

Możesz nawet wykonać majsterkowanie za pomocą plików płaskich SQL, które modyfikują schemat i aktualizują wersję schematu. Wszystko, co naprawdę musisz zrobić, to:

  • trzymaj migracje obok kodu źródłowego, powinny one być wersjonowane i oznaczone razem
  • zawsze używaj zarządzanych zmian (migracji) we wszystkich środowiskach
  • nigdy nie zezwalaj na modyfikacje ad-hoc w żadnym środowisku

Cóż, możesz wprowadzać zmiany programistyczne w dev, ale zawsze powinieneś zdmuchnąć db i odbudować go z migracji po zarejestrowaniu zmiany.

dietbuddha
źródło
Co by się stało, gdyby w skryptach znaleziono błąd? Czy wracasz do skryptu SQL i go aktualizujesz?
judda
1
Nie, tworzysz nową migrację (która zwiększa wersję schematu). W ten sposób wiesz, że poprawka została wdrożona, patrząc na wersję schematu w bazie danych.
dietbuddha
Dziękuję za pomoc Na pierwszy rzut oka wydaje się, że jest to bardzo solidne podejście i podobne do naszej strategii rozgałęziania.
judda
2

Kontrola źródła!

Nie wdrażasz binarnych programów rozwojowych bezpośrednio na produkcje bez przechodzenia przez svn / git / p4. Dlaczego więc same bazy danych miałyby to robić? Uzyskaj prywatne wystąpienia dla programistów, aby przetestować ich lokalne zmiany, ale kiedy musi przejść do bazy danych rozwoju, musi przejść przez sprawdzone pliki ddl. Możesz nawet napisać narzędzia do automatycznego stosowania tych zmian ddl (nie znam żadnego istniejącego sposobu, aby zrobić to poprawnie).

Po wprowadzeniu ograniczeń dotyczących zmian schematu db (Koniec z sqlplus -> wystawienie ddl!) I ścisłej kontroli konta (brak dostępu ddl do wszystkich), powinno to stać się łatwiejsze do zarządzania.

Subu Sankara Subramanian
źródło
1
Niestety nasze bazy danych są zbyt duże, aby można je było przekazywać między programistami, aby uruchomić sesje prywatne. Wydaje się, że tak naprawdę nie skłania się ku rozwojowi zespołowemu, ponieważ w tej chwili pracuję nad rozwojem zaplecza, rozmawiając z ludźmi o pracy nad interfejsem użytkownika. Musiałbym zacząć od sprawdzenia wszystkich zmian, a następnie zmuszenia ich do uzyskania najnowszych danych w bazie danych, co wydaje się być dość dużym problemem.
judda
Dlaczego programista db musi mieć taki sam rozmiar jak db produkcyjny? Mogą mieć ten sam schemat, a nawet możesz mieć specjalną flotę testującą obciążenie ze wszystkimi danymi, ale lokalne bazy danych deweloperów mogą być małe. Zapobiega to również obawom o wyciek danych itp. - teoretycznie dane prod nie powinny w ogóle uderzać w rozwój.
Subu Sankara Subramanian
Wszystkie nasze dane są ładowane w procesie ładowania danych, który przetwarza pliki dostarczone nam od klienta, a następnie przekształca je w dane, których potrzebujemy. Dlatego nie jesteśmy w stanie oddzielić danych deweloperów i producentów, ponieważ wszystkie ładunki danych i tak wymagają weryfikacji w fazie projektowania. Myślę, że nie musi być tego samego rozmiaru, ale potrzebuje porównywalnych ilości danych, aby tworzone przez nas raporty generowały znaczące informacje.
judda
Cała baza danych nie musi być replikowana. W Oracle każdy użytkownik ma swój własny schemat, a my mamy jeden schemat aplikacji. Utwórz publiczne synonimy dla wszystkich obiektów w schemacie aplikacji. Następnie każdy użytkownik może zmienić obiekty (tabele, SP) we własnym schemacie i jeśli połączą się jak oni, zostaną użyte ich nazwy obiektów. W przypadku obiektów, których nie ma w schemacie, należy użyć synonimów. Tak pracujemy.
softveda
0

W następstwie sugestii użycia migracji ... być może użyj O / RM, który obsługuje migracje, takie jak Ruby on Rails i Entity Framework 4.3 Problem z obydwoma podejściami polega jednak na tym, że migracja to wszystko albo nic. Nie można (zwykle) wybrać, które migracje mają zostać zastosowane, podobnie jak w przypadku zestawów zmian.

Inną realną opcją (jeśli jesteś na stosie Microsoft, nigdy nie wspominałeś o platformie) jest zarządzanie SQL za pomocą narzędzi Visual Studio Database. Ma wbudowane refaktoryzację (zmiana nazwy / usuwanie kolumn itp.) I weryfikuje model. Jeśli na przykład przechowywany proc odwołuje się do kolumny, której już nie ma, poinformuje o tym.

Michael Brown
źródło