Czy można aktualizować produkcyjną bazę danych za pomocą migracji EF?

Zgodnie z Ten post na blogu większość firm korzystających z migracji EF podobno nie aktualizuje schematu bazy danych produkcyjnych baz danych za pomocą migracji EF. Zamiast tego autor posta na blogu zaleca stosowanie skryptów aktualizacji schematu jako części procesu wdrażania.

Używam skryptów aktualizacji schematu od kilku lat i podczas ich pracy planowałem użyć migracji EF zamiast w przyszłości z następujących powodów:

  • szybsze wdrażanie, mniej downtime
  • prostsza procedura rozmieszczenia
  • znacznie łatwiejsza migracja istniejących danych niż byłaby możliwa dzięki T-SQL
  • bardziej zrozumiała składnia zmian oczekujących na zastosowanie(Klasa DbMigration z czystą składnią C# VS. niezgrabny skrypt migracji T-SQL w tradycyjnym środowisku).
  • istnieje łatwa i szybka ścieżka downgrade do starego schematu db, jeśli wdrożenie nowej wersji oprogramowania nie powiedzie się

Jeden powód, dla którego mogę o tym myśleć zakazanie używania EF do migracji dB produkcji byłoby gdyby schemat DB został zmieniony tylko przez DBAs w przeciwieństwie do deweloperów. Jestem jednak zarówno dba, jak i developerem, więc w moim przypadku nie ma to znaczenia.

Więc jakie jest ryzyko aktualizacji bazy produkcyjnej przy użyciu EF?

Edit: chciałbym dodać, że jak już zasugerował solomon8718, zawsze ciągnę świeżą kopię produkcyjnej bazy danych do mojego serwera pośredniczącego i testuję migracje EF, które mają być zastosowane na serwer pośredniczący przed zastosowaniem go na serwerze produkcyjnym. IMO jest to niezbędne dla każdej aktualizacji schematu do systemu produkcyjnego, niezależnie od tego, czy używam migracji EF, czy nie.

Author: George Stocker, 2015-04-20
Source

4 answers

Spróbuję i tak odpowiedzieć. Powiedziałbym, że nie, nie ma powodu, aby nie używać kodu pierwsze migracje w produkcji. Po tym wszystkim, jaki jest sens tego łatwego w użyciu systemu, jeśli nie można go do końca?

Największe problemy, jakie z nim widzę, to wszystkie problemy, które możesz mieć z dowolnym systemem, które już zauważyłeś. Tak długo, jak cały zespół (w tym dba, jeśli dotyczy) jest na jego pokładzie, myślę, że umożliwienie EF zarządzania schematem poprzez migracje jest mniej skomplikowane, a stąd mniej podatne na błędy niż tradycyjne zarządzanie oparte na skryptach. I tak zrobiłbym kopię zapasową przed wykonaniem migracji na systemie produkcyjnym, ale i tak byś to zrobił.

Nie ma nic, co mówi, że DBA nie może wykonać migracji z Visual Studio. Dostęp może być nadal zablokowany z uprawnieniami na poziomie bazy danych, a on / ona może przejrzeć migrację (w pomocnym formacie eksportu SQL przy użyciu -Script, w razie potrzeby) przed wykonaniem rzeczywistej operacji. Wtedy nadal są pod kontrolą, ale możesz użyć migracji kodu. Może nawet im się spodoba!

Aktualizacja: ponieważ Sprocks i TVFs zostały wychowane, zajmujemy się tymi w migracjach, jak również, chociaż są one rzeczywiście wykonane z prostych poleceń SQL za pomocą DbMigration.Sql() wywołanie w Up(), a odwrotnie z nich w Down() (można również użyć CreateStoredProcedure i DropStoredProcedure dla prostych Sprocks, ale myślę, że nadal trzeba zdefiniować ciało w SQL). Chyba można powiedzieć, że to zastrzeżenie; tam nie jest jeszcze sposobem, aby cała, obszerna baza danych została napisana wyłącznie w C#. Jednak Można używać migracji zawierających skrypty SQL do zarządzania całym schematem. Jedną z zalet tego procesu jest to, że można użyć pliku konfiguracyjnego C# dla nazw obiektów schematu (na przykład różnych nazw serwerów dla produkcji vs dev) za pomocą prostej String.Format, połączonej z transformacją XML dla samych plików konfiguracyjnych.

 28
Author: DrewJordan,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2015-04-21 13:23:07

Tak istnieją dobre powody , aby nie używać zautomatyzowanego systemu, takiego jak Code First Migrations do wprowadzania produkcji zmian w bazie danych. Ale jak zawsze są wyjątki od zasad.

  1. Jednym z powodów, o których wspomniano, były uprawnienia dostępu, które byłyby bezpośrednio związane z zasadami zarządzania zmianami i zasadami bezpieczeństwa organizacji.

  2. Innym powodem byłby poziom zaufania do samego narzędzia migracji. Czy na pewno narzędzie nie ma w nim błędu? Co się stanie, jeśli narzędzie zawiedzie w połowie drogi? Czy jesteś pewien, że masz aktualne kopie zapasowe i proces, który można wycofać w razie potrzeby?

  3. Skrypty zmiany mogą wykonywać nieoczekiwane lub nieefektywne Skrypty. Doświadczyłem przypadków, w których wygenerowany sql skopiował dane do tabeli tymczasowej, upuścił oryginalną tabelę, a następnie odtworzył oryginalną tabelę dla rzeczy takich jak dodanie nowej kolumny, jeśli przypadkowo (lub celowo) zmienisz kolejność, w której pojawi się kolumna lub po zmianie nazwy tabeli. Jeśli chodzi o miliony rekordów, może to spowodować poważne problemy z wydajnością.

Moja rekomendacja:

Zakładając, że masz bazę danych, która odzwierciedla twój schemat produkcyjny, użyj narzędzia migracje, aby wygenerować Skrypty zmian w tym systemie. Zwykle przed uruchomieniem przywracamy naszą bazę danych stage ze świeżej kopii produkcyjnej. Następnie sprawdzamy Skrypty zmian ręcznie, aby sprawdzić, czy nie występują problemy. Po tym my Uruchom skrypty z naszą bazą danych stage, aby upewnić się, że jest poprawnie wykonywana i że wszystkie spodziewane zmiany miały miejsce. Teraz jesteśmy pewni, że skrypty są zarówno bezpieczne do uruchomienia w produkcji, jak i wykonywania oczekiwanych zmian. Proces ten dotyczyłby wszystkich trzech kwestii wymienionych powyżej.

 28
Author: MplsAmigo,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2015-04-20 19:21:05

Inne zastrzeżenie, które znalazłem: jeśli masz kilka stron internetowych korzystających z tego samego kontekstu danych, musisz upewnić się, że wszystkie z nich są aktualizowane w tym samym czasie. W przeciwnym razie może istnieć ciągła walka o aktualizację / downgrade bazy danych między stronami internetowymi. Poza tym, to działało dobrze dla mnie.

EDIT: moja własna perspektywa rok po rozpoczęciu stosowania migracji EF w produkcji:

EF Migrations jest rzeczywiście całkiem fajne, nawet do użytku produkcyjnego, pod warunkiem, że

  1. Przetestuj migracje na systemie przejściowym. Testuję wszystkie migracje, migrując w dół i w górę ponownie na moim serwerze CI przed uruchomieniem testów integracji.
  2. nie uruchamia migracji automatycznie, ale za pomocą pliku wsadowego uruchamianego przez administratora. Jest to zasadniczo to samo, co ręczne uruchamianie SQL dla migracji w SSMS.
 6
Author: Adrian Grigore,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2016-05-03 10:11:46

Używam go w produkcji do kilku projektów. Kiedy już to zrozumiesz, myślę, że będzie dobrze.

Podczas programowania możesz zachować włączoną automatyczną migrację, ale na końcu możesz połączyć się z live db bezpośrednio z konsoli Menedżera pakietów i wygenerować migrację. Zapewni Ci to jedną migrację dla wszystkich zmian.

Ale zawsze Zawsze używaj opcji -script z update-database i sam odpal SQL.

Radziłbym też nie używać opcji update db z web deploy. W ten sposób nie ma sposobu, aby powiedzieć, ile migracji zostało już uruchomione na błąd. Kilka razy miałem z tym problemy. Więc najlepiej dostać SQL i odpalić go ręcznie.

 1
Author: Yashvit,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2017-01-11 11:36:26