Mein Team hat sich in den letzten Jahren immer mehr mit CMS beschäftigt. Wir sind auch immer mehr in die kontinuierliche Integration geraten. Beides in Einklang zu bringen, hat sich als schwierig erwiesen. Um es noch schlimmer zu machen, erstellen wir LAMP- und .NET-Sites, sodass unsere Skripte idealerweise für beide funktionieren.
Wir haben vier Umgebungen für jeden lokalen Standort, Integration, Staging und Produktion. Die Eingabe von Inhalten und das Hochladen von Dateien erfolgen regelmäßig auf der Produktionsseite. Die Entwicklung beginnt offensichtlich lokal und arbeitet sich nach oben.
Welche Methoden oder Techniken kann ich auf meinem Build-Server implementieren, um automatisch Daten- und Schemaaktualisierungen aus Entwicklungsumgebungen in die Produktion zu übertragen, ohne benutzergenerierte Inhalte zu überschreiben? Umgekehrt, wie (und wann) kann ich benutzergenerierte Daten automatisch in die Entwicklungsumgebungen ziehen?
Sie haben 3 Arten von Dingen in Ihrer Datenbank, um die Sie sich kümmern müssen.
1) Das Schema, das in DDL definiert werden kann. 2) Statische oder Lookup-Daten, die in DML definiert werden können. 3) Dynamische (oder Benutzer-)Daten, die auch in DML definiert werden können.
Normalerweise sollten Änderungen an (1) und (2) nur mit dem Code, auf den sie sich gegenseitig verlassen, in die Produktion gehen. (3) sollte nie hochgehen, kann aber in Entwicklungsumgebungen kopiert werden, wenn sie zu diesem Zeitpunkt mit Produktionsumgebungen synchronisiert sind.
Natürlich ist es viel komplizierter als das. Um (1) hochzufahren, kann es erforderlich sein, vorhandene Schemas/DDLs in spezifische Alter-Anweisungen umzuwandeln und möglicherweise auch Daten zu manipulieren, wenn sich Datentypen oder Speicherorte ändern. Um (2) hochzufahren, ist eine Synchronisation mit dem Code-Build erforderlich, was in komplexen Umgebungen schwierig werden kann.
Es gibt viele Tools, und wenn Sie Automatisierung benötigen, brauchen Sie wahrscheinlich Rat von jemandem, der damit vertraut ist.
Ich verwende ein sehr einfaches Schema, bei dem alle Schemaänderungen in einem SQL-Erstellungsskript widergespiegelt und auch zu einem SQL-Änderungsskript hinzugefügt werden, das alle erforderlichen SQL-Anweisungen enthält, um alle erforderlichen Transformationen durchzuführen. Das funktioniert gut für mich, aber mein Szenario ist sehr einfach (1 Person, 1 Server) und daher untypisch.
Der Schlüssel zum Erfolg liegt jedoch darin, die für die Änderungen erforderliche Arbeit zum Zeitpunkt der Änderung zu definieren. Die naive Methode, einfach die Entwicklungsdatenbank zu ändern und dann zur Bereitstellungszeit eine Behebung durchzuführen, ist eine Katastrophe.
Für A) ist es am besten, ein Prioritätssystem zu verwenden. Wo Ihr Inhalt “Standard” ist und der Benutzerinhalt ihn “überschreibt”. Und dieser Inhalt befindet sich an zwei verschiedenen Orten. So aktualisieren Sie Ihre Daten ohne die Möglichkeit, sich mit einem Zusammenführungsprozess auseinandersetzen zu müssen. Ihre Daten können sich in einem anderen Verzeichnis befinden oder in der DB anders gekennzeichnet sein, was auch immer. Der Nachteil dabei ist, dass Sie nicht einfach die standardmäßige Serverfunktionalität verwenden können, um die Daten zu servern, es sei denn, Sie nehmen die eigentliche Zuordnung vor, wenn die Links generiert werden.
dh Sie können entweder /site/images/icon.png abfangen und entweder /site/images/default/icon.png oder /site/images/client/icon.png bereitstellen oder wenn Sie die Seiten schreiben, können Sie die Überprüfung durchführen dort und senden Sie die richtigen URLs, damit der Server sie direkt bedienen kann.
Zweitens, wann Sie die Kundendaten verwenden können, ist das eher ein rechtliches IP-Problem, das Sie mit dem Kunden darüber besprechen müssten, ob er a) bereit und b) sogar in der Lage ist, seine Inhalte mit Ihnen zu teilen . Danach ist die Technik unkompliziert.
13676600cookie-checkAutomatisierte Datenbankbereitstellungen mit nutzergenerierten Inhalten (a la CMSes)yes