Jak skonfigurować proces tworzenia lokalnej bazy danych dla małego zespołu internetowego?

tło

Pracuję nad stworzeniem nowego procesu rozwoju dla małego zespołu internetowego złożonego z około 4 programistów i 4 projektantów, z oczywistym potencjałem do rozwoju zespołu w przyszłości. Nasz produkt to centralna aplikacja, która zasila witryny klienckie, które również projektujemy i hostujemy.

Wcześniej wszyscy pracowaliśmy przez FTP na serwerze deweloperskim z jedną bazą danych deweloperów. Przez pewien czas „działało” ^* , ale zmierzamy w nowym kierunku, więc nadszedł czas, aby dojrzeć nasz proces.

Używamy Percona Server 5.5, ale powinna to być agnostyka bazy danych, z myślą o utrzymaniu niskich kosztów.

Cele :

Zastanawiam się nad stworzeniem procesu ciągłej integracji (CI) dla rozwoju bazy danych, mając na uwadze:

1. Programiści mają lokalną kopię danych, na której można uruchomić kod programistyczny
2. Możliwość przywrócenia struktury bazy danych do poprzedniego zestawu zmian
3. Potrafi oddzielić nowe zmiany schematu funkcji od zmian poprawki projektu schematu
4. Potrafi lokalnie modyfikować strukturę bazy danych do testowania

Wstępna koncepcja

Naszkicowałem proces poniżej za pomocą SVN i LiquiBase, chociaż całkowicie go usuwa #4.

• utwórz gałąź „rozwoju” z pnia
• centralny serwer db „rozwoju” działa z gałęzi „rozwoju”
• lokalni programiści są skonfigurowani jako niewolnicy gałęzi programistycznej ( #1powyżej)
• zestawy zmian likibase są regularnie przydzielane do gałęzi programistycznej, która wykonuje przechwycenie po zatwierdzeniu, aby zaktualizować centralną bazę danych programowania (która spłynie do lokalnych maszyn działających jako slave na tym serwerze programistycznym) (likibase zapewnia #2powyżej)
• gdy funkcje lub poprawki schematu są gotowe do przejścia do kontroli jakości, DBA (ja) połączy odpowiednie zmiany z gałęzi programistycznej do magistrali. Ten akt spowoduje utworzenie skryptu SQL do zastosowania na pomostowym serwerze bazy danych.
• Serwer pomostowy powinien odzwierciedlać TRUNK, który powinien mieć taką samą strukturę jak Produkcja, a także zmiany w kontroli jakości
• po wykonaniu skryptu SQL na serwerze pomostowym wykonaj kontrolę jakości zmian.
• Jeśli wszystko wygląda dobrze, TAGUJ strukturę. Spowoduje to wygenerowanie skryptu .sql do ręcznego uruchomienia w środowisku produkcyjnym przez DBA (w razie potrzeby poza godzinami szczytu)

Ten proces wymaga, aby wszyscy programiści uruchomili tę samą gałąź „rozwoju”, co oznacza, że ​​w danym momencie istnieje tylko jedna wersja schematu bazy danych (nie jestem pewien, czy tego chcę).

Oznacza to również, że wszelkie zmiany w schemacie nie mogą być testowane lokalnie i mogą mieć wpływ na innych programistów, jeśli nie zostaną wykonane prawidłowo. W naszym środowisku programiści mogą dodawać nowe tabele, ale rzadko modyfikują istniejącą strukturę. Jako DBA poprawki projektowe są wykonywane przeze mnie. Ale niemożność testowania poprawek lokalnie jest moim największym zawieszeniem tego procesu.

W jaki sposób można zmodyfikować powyższy proces, aby umożliwić rozwój lokalny, przy jednoczesnym zachowaniu stosunkowo aktualnej kopii danych (zgodnie z replikacją w moim proponowanym procesie)? Nie wymagam, aby dane były aktualne nawet do ostatniego tygodnia.

---

^* Przez „pracował” mam na myśli, że wystarczyło, ale był PITA.

Zarządzanie środowiskami

Myślę, że zdecydowanie nie chcesz być zmuszany do jednej wersji bazy danych. Masz wystarczająco dużo programistów, że nieuchronnie będziesz mieć wiele strumieni prac programistycznych i wymagania dotyczące stosowania poprawek do bieżącego środowiska produkcyjnego, niezależnie od strumieni prac programistycznych.

Możesz użyć Liquibase lub procesu ręcznego do tworzenia skryptów łatek do aktualizacji wersji. Sugeruję rozpoczęcie od procesu ręcznego i użycie narzędzia do porównywania schematów kontroli jakości w łatkach. Czysta, zautomatyzowana, przejrzysta synchronizacja nietrywialnie złożonej bazy danych jest nieco utopijna.

Twój centralny model danych może być przechowywany w dowolnym systemie, na jaki masz ochotę. Użyłem wszystkiego, od żmudnych narzędzi repozytorium korporacyjnego, do tworzenia skryptów tabel. Twórz skrypty tabel, grając ładnie za pomocą zwykłych narzędzi kontroli źródła, takich jak subversion, i nie wszystkie narzędzia repozytorium wykonują dobrą pracę z wersjonowaniem.

Czegokolwiek użyjesz jako repozytorium głównego modelu danych, potrzebujesz dość czystego mechanizmu do wdrażania środowiska z tego modelu. Powinien być tak skonstruowany, aby wdrażanie do środowiska było łatwe. Potrzebujesz także mechanizmu łatania z jednej wydanej wersji do następnej.

Co ja zrobiłem

W przeszłości zarządzałem środowiskami programistycznymi. Nie jest to szczególnie zaawansowana technologicznie, ale można ją kontrolować i zautomatyzować kompilację, więc ułatwia wdrożenie środowiska do określonej wersji, a obsługa dużej liczby środowisk jest dość praktyczna.

Utrzymuj centralne repozytorium: może to być zestaw skryptów do tworzenia baz danych przechowywanych w systemach kontroli wersji lub model repozytorium w narzędziu do modelowania danych. Wybierz swój. Ten model powinien mieć mechanizm kompilacji, który pozwala na wdrożenie środowiska ze skryptów bez konieczności ręcznej interwencji.

Jeśli masz dużo danych referencyjnych, potrzebujesz do tego mechanizmu ładowania. W zależności od tego, jak chcesz to zrobić, możesz przechowywać to w bazie danych lub w zestawie plików. Zaletą plików jest to, że można je również wersjonować i oznaczać etykietami z tego samego systemu kontroli wersji, co baza kodu. Kilka plików CSV i skryptów modułu ładującego luzem w repozytorium kontroli źródła może to zrobić dość łatwo.

Jedną z opcji wdrażania środowisk programistycznych jest pobranie kopii zapasowych produkcyjnej bazy danych załatanej do odpowiedniej wersji i udostępnienie ich deweloperom w celu przywrócenia do środowiska programistycznego.

Ułatwienie wdrożenia: jak w przypadku każdego procesu budowania CI, baza danych powinna być możliwa do wdrożenia z jednego skryptu. Skonfiguruj go tak, aby można było sparametryzować połączenia z bazą danych lub aby skrypt był niezależny od lokalizacji i mógł być po prostu uruchamiany przez połączenie.

Skrypty łatek: Będziesz musiał przejść do przodu i prawdopodobnie wycofać skrypty z każdej wydanej wersji.

Buduj środowiska testowe z modelu repozytorium: zapewnia to, że programowanie w środowiskach, które nie są zsynchronizowane z repozytorium, zostanie złapane w testowanie.

Przetestuj proces wdrażania: Zautomatyzowane skrypty do łatania, jednak są one tworzone, powinny być możliwe do przetestowania. Narzędzia do porównywania schematów są do tego całkiem dobre, nawet jeśli nie używasz ich do generowania skryptów łatek.

• Utwórz środowisko referencyjne z kompilacją modelu repozytorium, na której testowano

• Utwórz środowisko testowania dymu z kopią zapasową wersji produkcyjnej lub kompilacji opartej na aktualnie wydanej wersji.

• Uruchom skrypt poprawki w środowisku testu dymu.

• Użyj narzędzia do porównywania schematów, aby porównać środowisko testu dymu ze środowiskiem odniesienia. Skrypt poprawki powinien spowodować, że dwie bazy danych będą identyczne, abyś mógł zbadać wszelkie różnice.

Co lubię w tym procesie

Jest to nieco ciężkie i zostało zaprojektowane do wdrożenia w dość biurokratycznych i nieprzejrzystych środowiskach produkcyjnych. Ma jednak następujące zalety:

• Programiści mogą majstrować tam, gdzie muszą.

• Można uwzględnić wiele gałęzi i strumieni rozwoju.

• Same skrypty wdrażania można przetestować w powtarzalny sposób. Jest to bardzo pomocne w celu zamknięcia walk bunkierowych, ponieważ można wykazać powtarzalność.

• Narzędzia do porównywania schematów zapewniają kontrolę jakości samego wdrożenia.

• Testowanie odbywa się zawsze w stosunku do tego, co ma zostać wydane, a to wychwyci problemy wynikające z braku synchronizacji środowisk.

• Wdrożenie oparte na modelach repozytoriów i skryptach łatek oznacza, że ​​niekontrolowane śmieci nie zostaną przypadkowo przeniesione ze środowisk programistycznych do produkcji.

• Wiele z tych procesów można zautomatyzować, chociaż często pożądane jest ręczne przygotowanie i przetestowanie skryptów łaty wdrażania.

• Środowiska są tanie i łatwe do wdrożenia bez konieczności przeskakiwania przez obręcze.

• Deweloperzy zmuszeni są stworzyć system, który będzie podlegał prostemu procesowi kompilacji i wdrażania.

• Programiści muszą nauczyć się podstawowych zadań związanych z administrowaniem bazami danych, ale środowiska testowe i produkcyjne są odizolowane od błędów noob.

Jak spełnia twoje wymagania

1. Programiści dysponują lokalną kopią danych do uruchamiania kodu programistycznego
   
   . Skrypty wdrażania lub obrazy DB oznaczają, że mogą skonfigurować środowisko z dowolnej dostępnej wersji.

2. Możliwość przywrócenia struktury bazy danych do poprzedniego zestawu zmian
   
   Ponownie posortowane według skryptów wdrażania. Zarówno za pomocą DDL, jak i testowych obrazów kopii zapasowych bazy danych utworzonych w kontrolowanym procesie, programiści mogą wprowadzić środowisko do dowolnej określonej wersji.

3. Możliwość oddzielenia nowych zmian schematu funkcji od zmian poprawki projektu schematu
   
   Łaty do wspólnej wersji można zachować w osobnym rozwidleniu w drzewie svn. Jeśli kopie zapasowe bazy danych są używane jako środowiska odniesienia, muszą być przechowywane gdzieś w tej samej strukturze folderów, co rozgałęzienia projektów kontroli źródła.

4. Możliwość lokalnej modyfikacji struktury bazy danych w celu przetestowania
   
   Prosty proces wdrażania pozwala deweloperom majstrować i łatwo przywracać środowisko do stanu lokalnego lub wywoływać środowisko referencyjne w celu dokonywania porównań i dokonywania zestawów zmian.