Jak radzisz sobie z wdrożeniami zmian w bazie danych?

Dyskutowaliśmy dziś o technikach wdrażania baz danych, ponieważ mieliśmy kilka ostatnich błędów w naszym bieżącym procesie i widzieliśmy sytuacje, w których chcielibyśmy wycofać wdrożenie, ale stara wersja aplikacji nigdy nie była testowana z nową wersją Baza danych.

Z jednej strony istnieją wdrożenia w stylu migracji, w których masz instrukcję zwiększania wersji i instrukcję zmniejszania wersji (niezależnie od tego, czy są napisane w języku SQL, czy w języku aplikacji), a Twoja aplikacja wie, do której wersji musi się dostać.

Są one proste i ponieważ nie będziemy często wycofywać, programiści chętnie korzystają z prostych. Istnieje jednak ryzyko, gdy dodajesz pole / tabelę i pole to jest zapełniane przed wycofaniem. Lub gorzej, gdy upuszczasz dane, które były istotne dla poprzedniej wersji.

Z drugiej strony możemy rozważyć ulepszenie, wycofanie, podejście do przodu, w którym wycofanie nie jest tak drastyczne jak w przypadku migracji. Na przykład aktualizacja może dodać pole, które nie ma wartości zerowej; wycofanie powoduje, że jest zerowalne, więc stara aplikacja nie dba o to; funkcja rollforward zapełnia pola zerowe i sprawia, że ​​ponownie nie ma wartości null.

Zachowuje to dane, ale jest skomplikowane zarówno pod względem kodu, jak i testowania (niestety, nasze zautomatyzowane testy integracji prawie nie istnieją i podczas gdy my je naprawiamy, w międzyczasie mamy problem).

Czy istnieją bezpieczne sposoby na złagodzenie problemów z nimi? Czy są inne opcje, które powinienem rozważyć? Czy miałeś złe doświadczenia, którymi chciałbyś się podzielić, co może później zaoszczędzić mi bólu?

Zmiany w bazie danych powinny być obsługiwane jak wszystkie inne zmiany i wdrażane jako skrypty jako część wdrożenia (i oczywiście zapisywane w kontroli źródła). Ponieważ są one wdrażane z kodem dla tej samej wersji aplikacji, dokładnie wiesz, co należy wycofać. Możesz mieć ochotę i napisać skrypt, aby cofnąć każdą zmianę w momencie pisania skryptu bazy danych, ale jeśli wycofywanie nie jest powszechne, możesz tego nie chcieć. Jeśli zostanie wypełniona nowa kolumna, utracisz dane, jeśli wrócisz do oryginalnej bazy danych.

W SQL Server możesz zrobić migawkę tuż przed wdrożeniem, a następnie powrócić do niej natychmiast, jeśli wdrożenie się nie powiedzie. Zakłada się, że wdrożenie NIE ma miejsca, gdy użytkownicy są w systemie (nie chcesz utracić ich zmian danych). Jest to najbardziej przydatne podczas ważnej wersji, kiedy może być konieczne tymczasowe wyłączenie całego systemu, aby wykonać aktualizację. Lub nadal możesz zrobić migawkę i dokonać porównania bazy danych między migawką a bazą danych, aby zobaczyć różnice, jeśli trzeba cofnąć. Narzędzie takie jak SQLCompare może nawet wygenerować kod, aby wrócić do struktury migawki. Nie wiem, co jest dostępne dla innych baz danych.

Zmiany w strukturze bazy danych powinny być zautomatyzowane / skrypty i przetestowane przy użyciu środowiska testowego. Ręczne zmiany są zbyt ryzykowne w środowisku produkcyjnym

Jedyną rozsądną strategią wycofywania (ta z najmniejszym prawdopodobieństwem pogorszenia sytuacji) jest powrót do migawki sprzed aktualizacji. Jeśli coś pójdzie nie tak, albo nastąpi to wystarczająco szybko, aby można było wrócić do migawki, albo zbyt późno na wycofanie (następny raport na koniec tygodnia kończy się niepowodzeniem z powodu problemów w bazie danych).

Zmiany można wprowadzać stopniowo (np. Dodając pole), dzięki czemu są testowane na żywo z mniejszym ryzykiem niż przy wykonywaniu ich wszystkich za jednym razem.

Planując, możesz wprowadzić zmiany w bazie danych, aby obsługiwać kilka nadchodzących wydań, zamiast konfrontować oprogramowanie i aktualizację bazy danych z każdym wydaniem.

Przygotuj się na tryb awaryjny w dniach następujących po aktualizacji bazy danych, tak jak w przypadku aktualizacji oprogramowania.

Oprzyj się pokusie ręcznego łatania problemów. Użyj swojej strategii awaryjnej (wycofanie, migawka), a następnie pomyśl, dlaczego coś poszło nie tak, zanim spróbujesz ponownie zaktualizować.