Ich denke, dieses Problem besteht aus zwei Teilen.
Zuerst verwaltet man das Datenbankschema und seine Änderungen. Wir tun dies mit South und behalten sowohl die Arbeitsmodelle als auch die Migrationsdateien in unserem SCM-Repository. Aus Sicherheitsgründen (oder Paranoia) machen wir einen Dump der Datenbank, bevor (und wenn wir wirklich Angst haben, auch danach) Migrationen durchgeführt werden. South war bisher für alle unsere Anforderungen ausreichend.
Zweitens wird die Schemaänderung bereitgestellt, die über das bloße Ausführen der von South generierten Migrationsdatei hinausgeht. Meiner Erfahrung nach erfordert eine Änderung an der Datenbank normalerweise eine Änderung am bereitgestellten Code. Wenn Sie auch nur eine kleine Webfarm haben, ist es möglicherweise nicht trivial, den bereitgestellten Code mit der aktuellen Version Ihres Datenbankschemas zu synchronisieren – dies wird noch schlimmer, wenn Sie die verschiedenen Caching-Ebenen und die Auswirkungen auf einen bereits aktiven Site-Benutzer berücksichtigen. Verschiedene Websites gehen unterschiedlich mit diesem Problem um, und ich glaube nicht, dass es eine allgemeingültige Antwort gibt.
Die Lösung des zweiten Teils dieses Problems ist nicht unbedingt einfach. Ich glaube nicht, dass es einen einheitlichen Ansatz gibt, und es gibt nicht genügend Informationen über Ihre Website und Umgebung, um eine Lösung vorzuschlagen, die für Ihre Situation am besten geeignet wäre. Ich denke jedoch, dass es einige Überlegungen gibt, die berücksichtigt werden können, um die Bereitstellung in den meisten Situationen zu erleichtern.
In einigen Fällen ist es eine Option, die gesamte Website (Webserver und Datenbank) offline zu schalten. Dies ist sicherlich die einfachste Art, Updates zu verwalten. Aber häufige Ausfallzeiten (auch wenn geplant) können ein guter Weg sein, um unsere Geschäfte schnell zu erledigen, machen es mühsam, selbst kleine Codeänderungen bereitzustellen, und können viele Stunden dauern, wenn Sie einen großen Datensatz und/oder eine komplexe Migration haben. Für Websites, die ich bei der Verwaltung behilflich bin (die alle intern sind und im Allgemeinen nur während der Arbeitszeit an Werktagen verwendet werden), wirkt dieser Ansatz Wunder.
Seien Sie vorsichtig, wenn Sie die Änderungen an einer Kopie Ihrer Master-Datenbank vornehmen. Das Hauptproblem hierbei ist, dass Ihre Site noch aktiv ist und vermutlich Schreibvorgänge in die Datenbank akzeptiert. Was passiert mit Daten, die in die Master-Datenbank geschrieben werden, während Sie damit beschäftigt sind, den Klon für die spätere Verwendung zu migrieren? Ihre Website muss entweder die ganze Zeit abgeschaltet sein oder vorübergehend in einen schreibgeschützten Zustand versetzt werden, sonst gehen sie verloren.
Wenn Ihre Änderungen abwärtskompatibel sind und Sie eine Webfarm haben, können Sie manchmal damit durchkommen, den Live-Produktionsdatenbankserver zu aktualisieren (was meiner Meinung nach in den meisten Situationen unvermeidlich ist) und dann die Knoten in der Farm inkrementell zu aktualisieren, indem Sie sie aus dem entfernen Lastenausgleich für kurze Zeit. Dies kann gut funktionieren - das Hauptproblem hier ist jedoch, wenn ein bereits aktualisierter Knoten eine Anfrage nach einer URL sendet, die von einem älteren Knoten nicht unterstützt wird, werden Sie fehlschlagen, da Sie dies auf Load Balancer-Ebene nicht verwalten können.
Ich habe ein paar andere Wege gesehen/gehört, die gut funktionieren.
Die erste besteht darin, alle Codeänderungen in eine Funktionssperre einzuschließen, die dann zur Laufzeit über einige Site-weite Konfigurationsoptionen konfiguriert werden kann. Dies bedeutet im Wesentlichen, dass Sie Code freigeben können, bei dem alle Ihre Änderungen deaktiviert sind, und dann, nachdem Sie alle erforderlichen Aktualisierungen an Ihren Servern vorgenommen haben, Ihre Konfigurationsoption ändern, um die Funktion zu aktivieren. Aber das macht ziemlich schweren Code...
Die zweite besteht darin, den Code die Migration verwalten zu lassen. Ich habe von Websites gehört, auf denen Änderungen am Code so geschrieben sind, dass die Migration zur Laufzeit durchgeführt wird. Es ist in der Lage, die Version des verwendeten Schemas und das Format der zurückerhaltenen Daten zu erkennen - wenn die Daten aus dem alten Schema stammen, führt es die Migration an Ort und Stelle durch, wenn die Daten bereits aus dem neuen Schema stammen, tut es nichts . Von der natürlichen Nutzung der Website wird ein großer Teil Ihrer Daten von Personen migriert, die die Website verwenden, den Rest können Sie jederzeit mit einem Migrationsskript erledigen.
Aber ich denke, an diesem Punkt wird Google Ihr Freund, denn wie gesagt, die Lösung ist sehr kontextspezifisch und ich mache mir Sorgen, dass diese Antwort bedeutungslos wird ... Suchen Sie nach etwas wie "Zero Down Time Deployment" und Sie' Sie erhalten Ergebnisse wie dies mit vielen Ideen...
