Ruckusing Migrations część 1- teoria

Wersjonowanie bazy danych prostym tematem nie jest. Nie dla wszystkich. I o ile wersjonowanie „zwykłych” plików tekstowych zawierających kod jest sprawą jasną i prostą to jak zachowywać różne wersje czasami bardzo skomplikowanych schematów baz danych? Czy wersjonować samą tylko strukturę czy także dane? I wreszcie jak aktualizować bazę na „produkcji” – wszak wykonywanie aktualizacji „ręcznie” jest obarczone wysokim prawdopodobieństwem popełnienia zwykłego ludzkiego błędu. 

Co robić? Jak żyć?

Temat wersjonowania wydaje się na tyle skomplikowany, że wiele osób nie podejmuje nawet próby wyszukania narzędzia, które ułatwiło by zadanie. A nie trzeba zbyt długo i głęboko szukać. Znalezienie takiego rozwiązania jak framework Ruckusing nie powinno zająć więcej niż 10 minut. Idea tego narzędzia została zapożyczona (a jakże!) z systemu migracji wbudowanego w Ruby on Rails.

Jak to działa?

Ruckusing przechowuje kolejne aktualizacje bazy w klasach PHP, które zawierają kod wprowadzający zmiany w bazie. Każdy plik generowany jest za pomocą odpowiedniego polecenia w CLI. Nazwa każdego pliku jest poprzedzona datą i czasem, w którym został wygenerowany co utrudnia przypadkowe stworzenie dwóch plików o tej samej nazwie. Po wypełnieniu klasy kodem opisującym naszą aktualizację wracamy na chwilę do CLI – wydajemy polecenie odpowiadające za wprowadzenie zmian i już mamy zaktualizowaną bazę danych. Za pomocą jednego polecenia wprowadzone do bazy mamy nawet bardzo skomplikowane aktualizacje. Informacje o tym jakie zmiany zostały już wprowadzone do bazy przechowywane są w tabeli db_schema w postaci kolejnych rekordów zawierających przedrostek nazw plików (ten z datą i czasem).

Jak dodać do Ruckusing projektu?

Konfiguracja jest bardzo prosta i sprowadza się w zasadzie do dodania nowej zależności dla Composera:

Następnie wpisujemy composer update i już mamy zainstalowany framework.

Jak skonfigurować?

W katalogu głównym frameworku znajduje się katalog config a w nim z kolei szablon pliku konfiguracyjnego (database.inc.php). Plik ten należy skopiować do głównego katalogu biblioteki i zmienić jego nazwę na ruckusing.conf.php.  Sama biblioteka obsługuje bazy MySql, PostgresSql i SqlLite. Tak więc gdy otworzymy plik ruckusing.conf.php zobaczymy w nim tablice asocjacyjną z przykładowymi szablonami konfiguracji dla każdej z typów baz. Każda z przykładowych konfiguracji zapisana jest w odpowiednim kluczu (np. development). Jest to nazwa środowiska w jakim działa baza danych. Możemy tworzyć rzecz jasna własne środowiska poprzez dodawanie nowych kluczy i w jednym pliku przechowywać różne konfiguracje dla różnych środowisk.

Jeśli chodzi natomiast o konfiguracje samego połączenia z bazą to zapewne będziecie wiedzieć jak uzupełnić wszystkie dane poza directory. Ten parametr odpowiada za nazwę katalogu, w którym będą przechowywane pliki opisujące zmiany w bazie danych. Istotne jest aby w naszym środowisku developerski i w środowisku produkcyjnym ten katalog miał tą samą nazwę dzięki czemu gdy będziemy pobierać, commitować zmiany i później pobierać do wersji produkcyjnej wszystko będzie w jednym katalogu i będzie można łatwo wprowadzić zmiany na „produkcji”.

Ostatnią zmianą jaką należy wprowadzić w pliku konfiguracyjnym jest usunięcie fragmentu kodu („. ‘..’ ”) znajdującego się na samym końcu linii.

Jak zainstalować?

Po odpowiedniej modyfikacji pliku konfiguracyjnego przechodzimy do CLI i wykonujemy (w tym samym katalogu plik konfiguracyjny biblioteki) następujące polecenie:

To polecenie spowoduje dodanie do bazy tabeli db_schema.

Kiedy następna część?

Jeszcze w tym miesiącu. Mam nadzieję, że rozwiązanie opisane w tym poście wam się spodobało i w przyszłości ułatwi rozwiązywanie problemów związanych z wersjonowaniem bazy danych. Do przeczytania już wkrótce.

Posty które mogą Cię zainteresować:

5 Responses to Ruckusing Migrations część 1- teoria
  1. Mikołaj Jeziorny Odpowiedz

    Bardzo podobny system zastosowano w codeigniter. Jest całkiem spoko, tylko niestety trzeba samemu pisać commit. W django jest to automatyczne, ale wiąże się z tym, że tak są deklarowane całe modele tak, że django automatycznie tworzy również całą tabelę.
    Napewno do wersjonowania bazy danych tak wygodanie jak plików przy pomocy gita jeszcze daleko, ale przynajmniej są już jakieś konkretne pomysły. Podsyłam link do dropboxa gdzie masz screenshot z migracji w moim obecnie rozwijanym projekcie w CI: https://www.dropbox.com/s/xmxd93i2i7hollx/Zrzut%20ekranu%202016-01-11%2003.47.35.png?dl=0

    • Michał Janicki Odpowiedz

      O czyżby kolega przeniósł się na Maca i Atoma? Do rzeczy jednak. Generalnie wersjonowanie bazy w takiej postaci jak opisałem tutaj jest wygodne (napewno wygodniejsze niż przechowywanie plików sql ze zmianami) a najwygodniejsze jest wtedy gdy używa się takiego systemu od samego początku. W wersjonowaniu i tak najważniejsze jest to aby można było dość łatwo ogarnąć zmiany i nie wchodzić przypadkiem kolegom w drogę (znaczy jest ważne jeszcze kilka innych rzeczy ale mniejsza o to). A skoro kod PHP można wersjonować bez problemu to i nie będzie problemu z wersjonowaniem zmian w db opisanych w PHP. Po prostu więcej PHP i tyle 😉

      • Mikołaj Jeziorny Odpowiedz

        Przepraszam, że tak długi czas nie odpowiedziałem. Jednak byłem święcie przekonany, że twoja odpowiedź na komentarz będzie okraszona emailem. Ale owszem, przeniosłem się na Mac oraz Atom. Nie wiem, czy pamiętasz, ale w RCC rozmawialiśmy na temat tego, że myślę o kupnie macka. Przekonałeś mnie wtedy, że jest to sprzęt oraz oprogramowanie warte uwagi, nie żałuję. Krótko po zakupie przeszedłem też na Atoma, wcześniej zasoby lapka nie pozwalały mi na jego używanie więc go wykluczyłem. Teraz widzę, że był to błąd jest to naprawdę warty uwagi edytor. Dodatkowo, podpatrzyłem troszkę jak pracujesz i szczerze bardzo mi się spodobało kilka twoich rozwiązań. Przekonałem się nawet do graficznego gita ( sourcetree ) oraz używam vagranta. Środowisko jest dla developera bardzo istotne, a wielu o tym zapomina, może to jest fajny temat na wpis.
        Pozdrawiam.

      • Mikołaj Jeziorny Odpowiedz

        P.S
        Jeżeli realizował byś taki wpis kiedyś i byłbyś zainteresowany moimi rozwiązaniami oraz konfiguracjami, również środowisk serwerowych to pisz, zawsze chętnie zdobywam i dzielę się doświadczeniami i pomysłami.

        • Michał Janicki Odpowiedz

          Myślę o napisaniu czegoś na temat vagranta i możesz być pewien, że zgłoszę się do Ciebie jeśli faktycznie zabiorę się za taki post. Od kilku tygodni także pracuję na Atomie (trzecie podejście) i wreszcie się przekonałem. Kilka ostanych lat pracowałem na NetBeansie ale pod koniec tego roku miałem jedną rzecz szybko poprawić, uruchomiłem NB i oczywiście się zawiesił 😉 To zdarzenie przelało czarę goryczy, która napełniała się od ok 2 lat. Następnego dnia zainstalowałem kilka wtyczek i puki co nawet nie myślę o zmianie.

Dodaj komentarz

Your email address will not be published. Please enter your name, email and a comment.