„Żądamy sztywno określonych obszarów wątpliwości i niepewności!” - Douglas Adams

W tym poście opisano metodę rygorystycznego testowania migracji Entity Framework Core w szybki, zautomatyzowany i powtarzalny sposób w celu budowania zaufania podczas wypychania migracji do bazy danych w środowisku produkcyjnym.

Przykładowy kod tego rozwiązania jest na Githubie - mile widziane są wszelkie opinie!

Moim zdaniem migracje baz danych do środowiska produkcyjnego to część o najwyższym ryzyku związanym z aktualizacją produktu. Naprawdę jest tylko jeden strzał, a naprawianie błędów po wydarzeniu może być niezwykle trudne. Błąd migracji jest często „sytuacją awaryjną”, która wymaga od zespołów porzucenia wszystkiego i zajęcia się tym. Sposobem na uniknięcie tego potencjalnego chaosu są powtarzalne i zautomatyzowane testy, które są wykonywane przed przeniesieniem migracji, ale może to być trudne.

W tym poście przedstawię jeden ze sposobów testowania migracji danych, który moim zdaniem byłby świetny w utrzymaniu tętna programisty w zdrowym zakresie podczas aktualizacji bazy danych.

Zakładam tutaj przyzwoitą znajomość tworzenia baz danych, .NET core i migracji Entity Framework. Zakładam również dobrą znajomość TDD, testów jednostkowych i testów integracyjnych.

Dummy Domain

Aby zilustrować mój punkt widzenia, utworzyłem fikcyjną bazę danych. Zacznę od początkowej migracji, a następnie wykonam kolejną migrację, która modyfikuje schemat, a także niektóre dane, które były wcześniej przechowywane w bazie danych.

Ta struktura bazy danych umożliwia użytkownikowi utworzenie bloga, a następnie publikowanie w nim postów. Załóżmy, że to jest w produkcji, ktoś wskazuje, że przechowywanie „AuthorName” jako ciągu znaków to trochę błąd normalizacji, a to naprawdę powinno być przechowywane w osobnej tabeli.

Wprowadzenie tej zmiany wymaga zmiany schematu, a także migracji danych.

Co dzieje się „po wyjęciu z pudełka”

Tego rodzaju transformacje schematów są łatwo obsługiwane przez Entity Framework, które wypluwają automatycznie generowane pliki migracji. Te automatycznie generowane migracje zastosują transformację schematu , ale niestety tak naprawdę nie ma sposobu na zautomatyzowanie transformacji danych . Będzie to musiało zostać zrobione moją ręką, przenosząc dane z kolumny „AuthorName” do pliku. Tabela „Autor” i poprawnie podłączenie kluczy obcych.

Podczas procesu rozwoju te migracje będą najpierw uruchamiane na maszynie deweloperskiej, a następnie prawdopodobnie (miejmy nadzieję) w potoku i środowisku pre-prod. Dane w tych deweloperskich / testowych bazach danych są często minimalne i / lub wyidealizowane i jest mało prawdopodobne, aby reprezentowały dane znalezione w produkcyjnej bazie danych. Może to skończyć się migracjami, które przejdą w środowiskach testowych, a następnie zakończą się niepowodzeniem w środowisku produkcyjnym - scenariusz trochę koszmar!

Aby mieć pewność, że migracja będzie działać w środowisku produkcyjnym, potrzebujesz szybkich, zautomatyzowanych i powtarzalnych testów skryptów migracji, które działają na danych o charakterze produkcyjnym.

Migration Testing Utopia

Właściwości, których szukam w tych testach to:

• Wszystkie testy muszą być zautomatyzowane, od konfiguracji do zerwania, i muszą być zdolne do pracy w CI / CD.
• Testy powinny przebiegać szybko.
• Wyniki powinny być powtarzalne.
• Testy powinny być wykonywane na danych „podobnych do produkcji”.
• Powielenie wszelkich problemów z danymi, które występują w środowisku produkcyjnym w zestawie testów, powinno być łatwe.

Bliższe spojrzenie

To jest seria testów, po jednym dla każdej dodanej migracji. Każdy test zawiera skrypt SQL, który wstawia dane istotne dla tej migracji. Wszystkie testy będą miały ten sam format:

• Skonfiguruj dane tak, aby reprezentowały stan bazy danych przed migracją.
• Zastosuj migrację „w górę” bazy danych. Jeśli podczas migracji zostaną zgłoszone wyjątki, test zakończy się niepowodzeniem.
• Zakładając, że migracja zakończyła się pomyślnie, sprawdź, czy dane zostały poprawnie przekształcone po jej wykonaniu.
• Zastosuj migrację w dół
• Sprawdź, czy dane są poprawne po zastosowaniu migracji „w dół”.
• Zastosuj ponownie migrację w górę, aby rozpocząć następny test.

Uruchamianie takich testów buduje dużą pewność, że dane zostaną poprawnie przekształcone. Bardzo łatwo jest również skonfigurować przypadki brzegowe i udowodnić, że będą działać, konfigurując dane w skryptach SQL uruchamianych podczas testów.

Podobnie jak same migracje, testy te są budowane jeden na drugim. Za każdym razem, gdy dodawana jest nowa migracja, dodawany jest nowy test. Dane modelowane dla poprzedniej migracji muszą być w stanie przepłynąć przez wszystkie migracje, aby ostatecznie dotrzeć najpóźniej. Korzyść z tego jest nieco subtelna, ale oznacza to, że nigdy nie powinieneś stawać w obliczu sytuacji, w której w produkcie zatrzymują się stare dane, które przyłapią Cię na wielu wdrożeniach w przyszłości.

Jeśli problem prześlizgnie się przez sieć i wystąpi problem podczas migracji działającej bazy danych, trywialne będzie zapisanie konkretnych danych, które spowodowały problem, do odpowiedniego skryptu testowego, a następnie rozwiązanie go przez czerwono-zieloną pętlę testu.

Wniosek

Jestem bardzo zainteresowany opiniami społeczności na temat tej techniki. Myślę, że możliwość szybkiego uruchomienia i przetestowania migracji w ten sposób ma prawdziwą wartość. Ale z pewnością nie zamierzam twierdzić, że znalazłem absolutnie najlepszy sposób, aby to zrobić!

Mam kilka obaw:

• Nie podoba mi się to, że testy muszą być wykonywane w ustalonej kolejności. W rzeczywistości nie są to testy jednostkowe.
• Może to wymagać dużo pracy. Czy warto?
• Będzie to wymagało wielu skryptów SQL. Nie mam nic przeciwko, ale dostrzegam w społeczności „wahanie”, czy w dzisiejszych czasach bezpośrednio zajmować się SQL.

Andy