Kontinuierliche Integration mit ersten Migrationen des EF-Codes

Question

Ich habe mich gefragt, ob ich die ersten Migrationen vollständig für die kontinuierliche Integration automatisieren könnte.

Derzeit meine kontinuierliche Integration einfach aktualisiert einfach die Code-Änderungen, aber ich manuell eine Migration, erzeugt und die Datenbank auf meinem Continuous Integration Server aktualisieren.

Ist es zuverlässig/möglich/empfohlen, die Migrationen zu generieren und die Datenbank automatisch zu aktualisieren?

Zum Beispiel:

Ich habe Benutzer mit Eigentum userId und Benutzernamen ein. Ich füge dann ein Eigentumsalter in den Code ein. Im aktuellen Szenario müsste ich eine Migration erstellen, die diese Änderung erfasst, und dann checke ich meine Änderungen an der Versionskontrolle ein. Die kontinuierliche Integration wird diese Änderung erkennen und die neue Version bereitstellen. Ich muss die Datenbank manuell aktualisieren (was automatisiert werden sollte).

Kann ich auch die Generierung der Migration überspringen, sodass ich einfach das Alter der Eigenschaft in den Code einfügen kann und die kontinuierliche Integration diese Migration generiert. Nicht sicher, ob dies empfohlen wird.

Answer 1

Ein Teil der kontinuierlichen Integration ist auch die Möglichkeit, fehlerhafte Änderungen zurückzusetzen, wenn sie die Tests nicht bestehen.

• Schreiben Sie Ihre Datenbank-Upgradeskripte so, dass sie auch heruntergestuft werden können?
• Erstellen Sie für jedes Commit einige Speicherpunkte oder Sicherungen?
• Würden Sie Daten in der Datenbank im Falle von Backup/Wiederherstellungen bei schlechten Commits verlieren?
• Was ist eine schlechte Änderung in der DDL selbst?

Das sind einige der Fragen, über die Sie nachdenken sollten, bevor Sie es implementieren.

Answer 2

Die Antwort ist ja, aber nicht ganz, wie Sie beschreiben.

Sie müssen und müssen die Migration manuell generieren. Nicht alle Migrationen können automatisch erstellt werden. In diesen Fällen ist eine manuelle Änderung der generierten Migration erforderlich. Spaltenaufteilung, bestimmte Arten von Datentypänderungen usw.

Ihr CI-Server kann dann migrate.exe verwenden, um Ihre Datenbanken mit Ihrem Modell zu synchronisieren. Der schwierige Teil besteht darin, Migrationen zu behandeln, die zu Downgrades führen. Der Übergang von v1 zu v2 ist einfach, aber von v2 zurück zu v1 ist kniffliger, da nur die v2-Assembly weiß, wie man "zurück" zu v1 bekommt.

Am Ende habe ich ein benutzerdefiniertes Tool erstellt, das Migrationen intelligent ausführt und automatisch bestimmt, welche Modell- (Kontext-) Assembly für die Migration verwendet wird. Sie können hier eine Vorstellung davon bekommen, wie man das macht: EF Code First Migrations to Deploy Older Version

Das Endergebnis ist, dass ich eine Modelländerung/Migration einchecken kann und weiß, dass meine DB-Änderung automatisch in jede Umgebung implementiert wird, die Teil meiner ci/CD-Pipeline - und ja, das schließt Produktion mit ein.