Die Migration erfolgt von der lokalen Umgebung in die Produktionsumgebung. Die Produktionsumgebung ist einige Zeit gelaufen und hat viele Artikel erstellt.
Um meiner Site neue Dinge hinzuzufügen, habe ich ein benutzerdefiniertes Design hinzugefügt und CCK, Ansichten und andere Module in meiner lokalen Testumgebung installiert. Wie migriere ich die lokale Testumgebung nach Abschluss in die Produktionsumgebung, ohne den Inhalt der Datenbank zu zerstören?
Antworten:
Dies ist ein nicht triviales Problem, auf das fast jeder eine andere Antwort hat: Es gibt keine kanonische Drupal-Methode, um die Inszenierung für Produktionsschübe zu handhaben. Dries Buytaert, der die Drupal-Show leitet, hat sie zu einer der Schlüsselinitiativen von Drupal 8 gemacht . Natürlich wurde Drupal 7 gerade erst veröffentlicht, es wird also noch eine Weile dauern, bis es Früchte trägt.
Das Problem kann in zwei separate Punkte unterteilt werden:
Ersteres kann größtenteils vom Funktionsmodul übernommen werden, das Ihre Site-Konfiguration in ein Modul umwandelt, das Sie Ihrer Drupal-Installation hinzufügen können. Auf diese Weise können Sie es Ihrem Versionskontrollsystem hinzufügen, ohne sich darum kümmern zu müssen wird weggeblasen, wenn Sie Ihre Inhalte migrieren.
Letzteres ist sehr schwierig, da sich der Inhalt auf einer aktiven Site wahrscheinlich auch nach der ersten Synchronisierung mit Ihrer Entwicklungsumgebung während der Produktion ändert. Auf diese Weise wird verhindert, dass Inhalte während der Bereitstellung vollständig ersetzt werden, wie dies bei der Konfiguration der Fall ist.
Darüber hinaus verwendet Drupal keine UUIDs (Universal Unique Identifiers) für Inhalte: Jedes Mal, wenn ein Knoten oder ein Benutzer hinzugefügt wird, wird die ID um eins erhöht. Das heißt, Knoten 45 auf Ihrer Entwicklungssite ist möglicherweise Knoten 90 auf Ihrer Produktionssite.
Leider habe ich keine gute Lösung dafür: Die Bereitstellung von Inhalten ist eine echte Schwäche von Drupal. Ich persönlich füge nur Inhalte auf der Produktionsseite hinzu. Wenn ein Kunde sehen möchte, wie der Inhalt aussieht, bevor er live geschaltet wird, richte ich einen Klon der Produktionssite ein, auf den nur der Kunde zugreifen kann. Sobald die Genehmigung vorliegt, werden dieselben Änderungen direkt an der Produktion vorgenommen.
Es gibt noch eine andere Alternative, die sich herumwirbelt : das Bereitstellungsmodul . Es soll Services nutzen , um die Bereitstellung von Inhalten relativ einfach zu gestalten. Aber ich kann nicht für seine Wirksamkeit bürgen und es gibt keine Drupal 7-Version.
In unserem Prozess.
Wir verwenden Hudson, um unsere Entwicklungs- / Bereitstellungszweige neu zu erstellen, um Live- und Entwicklungszweige zu synchronisieren.
Da wir Git verwenden, hat jede Aufgabe, die wir ausführen, einen eigenen Zweig. Wenn dieser an die Qualitätssicherung übergeben wird, wird er zusammengeführt und als Staging-Server für Regressionstests verwendet.
Wenn der Master bereit ist, erstellen wir eine Testversion für unseren Server, Release Serverdie eine Live-Kopie (Konfiguration, Hardware usw.) ist.
Wir verwenden FeatureModule, um Konfigurationen bereitzustellen. Einige Dinge werden von der Funktion noch nicht unterstützt, daher verwenden wir hook_update_N und führen dann updatedb.php oder ausdrush -vd updb
drush fra --yes) aus, um alle überschriebenen Funktionen wiederherzustellen.Da wir Boost (Verschieben nach Varnish) und Memcache verwenden, müssen wir den Cache leeren ( drush cc all).
Wir verwenden Rsync, um unsere Bilder / Videos usw. zu synchronisieren.
Um von einem XAMPP-Server auf einen anderen Server zu migrieren, habe ich die Anweisungen auf dieser Site befolgt .
Stellen Sie sicher, dass Sie auf Ihrem Produktionsserver dieselbe Struktur beibehalten wie auf Ihrem Entwicklungsserver. Ich musste auch einige Dateien im Drupal-Administrator-Dashboard bearbeiten, das sich unter admin / config / media / file-system befand
Stellen Sie sicher, dass für den Pfad zum öffentlichen Dateisystem und das temporäre Verzeichnis die richtigen Speicherorte festgelegt sind.