Ich bin ein bisschen ein Continuous Delivery-Junkie und habe eine Leidenschaft für die Automatisierung von Build-, Test- und Bereitstellungsprozessen. Eine Sache, auf die ich wirklich Hilfe brauche, sind die Best Practices bei der Bereitstellung von Datenbankmigrationsskripten in einer automatisierten Bereitstellung. Dies sind die relevanten Details meines Technologie-Stacks.
Momentan bin ich in der Lage, unsere ASP.NET MVC-Website mit dem Web Deploy 2.0-Tool zu implementieren (wow, das hat Spaß gemacht!). MSDeploy hat einen 'dbFullSql'-Provider, der jedoch nur für die Bereitstellung ganzer Datenbanken und nicht für Migrationen verwendet werden kann. MSDeploy lässt die Tür offen für die Erweiterung mit dem 'runCommand'-Provider, um einen beliebigen Prozess auf dem entfernten Server auszuführen. Ich denke, dass ich in der Lage sein könnte, meine Migrationsskripte auf diese Weise auszuführen. Ich denke jedoch, dass es einen besseren Weg geben sollte, dies zu tun.
Beachten Sie beim Beantworten, dass ich MSDeploy für alle Interaktionen mit dem Remote-Implementierungsziel verwenden möchte. Wenn Sie jedoch ein Tool kennen, mit dem Migrationen sicher auf Remote-Ziele übertragen werden können, bei denen es sich nicht um MSDeploy handelt, würde mich das auch interessieren!
BEARBEITEN: Ein Beantworter (der seine Antwort gelöscht hat!) bezog sich auf den folgenden Artikel: Ссылка
Dies ist eine großartige Ressource, von der ich nicht wusste. Die meisten dieser Inhalte habe ich in der einen oder anderen Form gelesen und leider bestätigt dieser spezielle Artikel meine eigenen Vermutungen. Im Wesentlichen gibt es keine einfache Möglichkeit, benutzerdefinierte inkrementelle Updates mit den aktuellen Tools zu pushen (vaporware verspricht in künftigen Releases eine bessere Funktionalität im typischen MS-Stil).
In der Notiz zum Thema des Artikels erwähnt es.
... die Verwendung von VSDBCMD ist der empfohlene Ansatz für die inkrementelle Datenbank Veröffentlichung.
Allerdings kann VSDBCMD nur Delta-Skripts zwischen einer Quelle und einem Ziel generieren, denen ich bei einer Migration einfach nicht traue, insbesondere bei einer Produktionsbereitstellung. Die einzige Lösung, die der Artikel erwähnt, um inkrementelle Updates über Web Deploy zu pushen, ist das Erstellen einer benutzerdefinierten WPP-Zieldatei mit einem benutzerdefinierten SQL-Migrationsskript.
Sie können Web Deploy konfigurieren, um das SQL-Bereitstellungsskript auszuführen, das Datenbankprojekt erzeugt, aber um dies zu tun, müssen Sie Erstellen Sie eine benutzerdefinierte WPP-Zieldatei für Ihr Webanwendungsprojekt. Dies fügt der Bereitstellung eine erhebliche Komplexität hinzu verarbeiten. Darüber hinaus unterstützt Web Deploy nicht inkrementell Updates für bestehende Datenbanken. Für weitere Informationen zu diesem Ansatz, siehe Erweitern der Web-Publishing-Pipeline zum Packen des Datenbankprojekts bereitgestellte SQL-Datei .
Argh! Es sieht tatsächlich kompliziert aus. Ich habe darüber schon einmal gelesen und ich hatte gehofft, dass es einen besseren Weg geben würde. Zu diesem Zeitpunkt bin ich immer noch auf meinen MSDeploy 'runCommand' Provider angewiesen, der ein SQLCMD ausführt.
Sie können tatsächlich ein SQL-Skript als "Quelle" für den dbFullSql-Provider ( -source:dbfullsql="C:\sqlcmd.sql" ) angeben, und dieses Skript wird einfach ausgeführt. Ich habe dies bereits zuvor zur Bereitstellung mit einem benutzerdefinierten Migrationsskript-Verwaltungstool verwendet, das generiert.
Ich wünschte, Datenbankprojekte wären CD-freundlicher, da die "auto" -Arbeiten dazu neigen, schnell zusammenzufallen, wenn ein db-Refactor notwendig ist.
Web Deploy dbFullSql Provider Referenz
Tags und Links .net sql-server continuous-integration msdeploy webdeploy