Jak zarządzać bazami danych podczas tworzenia?

Do testowania integracji używamy lokalnych baz danych deweloperów i pojedynczej bazy danych master. Przechowujemy Skrypty tworzenia w SCM. Jeden programista jest odpowiedzialny za aktualizację skryptów SQL opartych na schemacie "golden master". Programista może w razie potrzeby wprowadzić zmiany do swojej lokalnej bazy danych, wypełniając je w razie potrzeby z danych w integration DB, wykorzystując proces importu lub generując dane za pomocą narzędzia (w naszym przypadku Red Gate Data Generator). W razie potrzeby deweloperzy wymazują swoje lokalne w razie potrzeby można kopiować i odświeżać dane ze skryptu tworzenia i integracji. Zazwyczaj bazy danych są używane tylko do testów integracyjnych i wyklejamy je do testów jednostkowych, więc ilość pracy utrzymującej synchronizację jest zminimalizowana.

Polecam przyjrzeć się poglądom Scotta Allensa w tej sprawie. Napisał serię blogów, które moim zdaniem są doskonałe. Trzy zasady pracy z bazami danych , The Baseline , Zmień Skrypty , Views, stored procs etc , rozgałęzianie i łączenie .

Używam tych wytycznych mniej lub bardziej, ze zmianami osobistymi i działają.

W przeszłości miałem do czynienia z tym na kilka sposobów.

Jednym z nich jest repozytorium skryptów SQL, które tworzy i wypełnia bazę danych. Nie jest to wcale zła opcja i może zachować wszystko w synchronizacji (nawet jeśli nie używasz tej metody, powinieneś nadal utrzymywać te skrypty, aby twój DB był pod kontrolą źródła).

Druga (którą preferuję) miała pojedynczą instancję "czystej" bazy dev na serwerze, z którą nikt się nie połączył. Kiedy programiści musieli odświeżyć swój dev bazy danych, uruchomili pakiet SSIS, który skopiował "czystą" bazę danych na ich kopię dev. Możemy wtedy modyfikować nasze dev-owe bazy danych w razie potrzeby, bez stawania na nogi innym programistom.

Mamy narzędzie do obsługi bazy danych, które tworzy/aktualizuje nasze tabele i nasze proc. mamy serwer, który ma aktualną bazę danych wypełnioną danymi.

Przechowujemy lokalne bazy danych, którymi możemy grać według własnego wyboru, ale kiedy musimy wrócić do "baseline", otrzymujemy kopię zapasową "master" z serwera i przywracamy ją lokalnie.

Jeśli / kiedy dodajemy kolumny/tabele / procs aktualizujemy narzędzie dbMaintenance, które jest utrzymywane w kontroli źródła.

Sometimes, its a ból, ale działa dość dobrze.

Jeśli używasz ORM, takiego jak nHibernate, Utwórz skrypt, który generuje zarówno schemat, jak i dane w lokalnej bazie deweloperów.

Popraw ten skrypt podczas tworzenia, aby zawierał typowe dane.

Przetestuj bazę danych przed wdrożeniem.

Wykonujemy replikację bazy produkcyjnej do bazy UAT dla użytkowników końcowych. Ta baza danych nie jest dostępna dla programistów.

Upuszczanie wszystkich tabel, tworzenie ich zajmuje mniej niż kilka sekund ponownie i wstrzyknąć dane testowe.

Jeśli używasz ORM, który generuje schemat, nie musisz utrzymywać skryptu tworzenia.

Wcześniej pracowałem nad produktem, który był związany z hurtownią danych i zaprojektowany do zainstalowania w witrynach klientów w razie potrzeby. W związku z tym program wiedział, jak przejść do "instalacji" (głównie stworzenie wymaganego schematu bazy danych i populacji danych statycznych, takich jak waluty / kody krajów, itp.).

Ponieważ mieliśmy te informacje w samym kodzie i ponieważ mieliśmy wtykowe Adaptery SQL, trywialne było uruchomienie tego kodu z bazą danych w pamięci (użyliśmy HSQL). W związku z tym wykonaliśmy większość naszych rzeczywistych prac rozwojowych i testów wydajności na "prawdziwych" serwerach lokalnych (Oracle lub SQL Server), ale wszystkie testy jednostkowe i inne zautomatyzowane zadania na specyficznych dla procesów DBs w pamięci.

Mieliśmy pod tym względem szczęście, że jeśli nastąpiła zmiana scentralizowanych danych statycznych, musieliśmy uwzględnić je w części aktualizacji instrukcji instalacji, więc domyślnie były przechowywane w repozytorium SCM, sprawdzonym przez programistów i zainstalowane jako część ich normalnego przepływu pracy. Po namyśle jest to bardzo podobne do proponowanego przez Ciebie pomysłu changelog DB, z wyjątkiem trochę bardziej sformalizowanego i z warstwą abstrakcji specyficznej dla domeny.

Ten schemat działał bardzo dobrze, ponieważ Każdy mógł zbudować w pełni działający DB z aktualnymi danymi statycznymi w ciągu kilku minut, bez nadepnięcia nikomu na palce. Nie mogłem powiedzieć, czy warto, jeśli nie potrzebujesz funkcji instalacji/aktualizacji, ale ja rozważyłby to i tak, ponieważ sprawiło, że zależność od bazy danych była całkowicie bezbolesna.

Co z tym podejściem:

Utrzymuj oddzielny repo dla "czystego db". Repo będzie plikiem sql z tabelą creates/inserts, itd.

Używając Rails (jestem pewien, że może być dostosowany do każdego repo git), utrzymuj "clean db" jako podmoduł w aplikacji. Napisz skrypt (być może zadanie rake), który odpycha lokalny dev db za pomocą instrukcji SQL.

Aby wyczyścić lokalny db (i zastąpić świeżymi danymi):

git submodule init
git submodule update

Then

rake dev_db:update ......... (or something like that!)

Zrobiłem jedną z dwóch rzeczy. W obu przypadkach programiści pracujący nad kodem, który może kolidować z innymi, uruchamiają własną bazę danych lokalnie lub uzyskują osobną instancję na serwerze bazy danych dev.

• Podobnie jak polecam @tvanfosson, masz zestaw skryptów SQL, które mogą budować bazę danych od podstaw, lub

• Na Dobrze zdefiniowanych, regularnych zasadach wszystkie bazy danych programistów są nadpisywane kopią danych produkcyjnych lub ze skalowaniem down / deidentifiked kopii produkcji, w zależności od rodzaju danych używamy.

Zgadzam się z tym wszystkim, co powiedział w swojej odpowiedzi. Jeśli używasz SQL Server, mamy rozwiązanie tutaj w Red Gate, które powinno umożliwić łatwe udostępnianie zmian między wieloma środowiskami programistycznymi.

Http://www.red-gate.com/products/sql_source_control/index.htm

Jeśli istnieją problemy z pamięcią masową, które utrudniają dba zezwalanie na wiele środowisk programistycznych, Red Gate ma na to rozwiązanie. Dzięki technologii HyperBac Red Gate możesz tworzenie wirtualnych baz danych dla każdego dewelopera. Wydają się być dokładnie takie same jak zwykła baza danych, ale w tle wspólne dane są współdzielone między różnymi bazami danych. Pozwala to programistom na posiadanie własnych baz danych bez zajmowania niepraktycznej ilości miejsca na serwerze SQL.