Wie entferne ich ein Modul in einer bereitgestellten Umgebung richtig?

Einige Module verfügen über Deinstallationsroutinen. Wobei normalerweise Datenbanktabellen für dieses Modul, Variablen aus der Variablentabelle und von diesem Modul eingeführte Gebietsschemata entfernt werden. Diese Routinen befinden sich in .installdiesem Modul.

Daher können sie nicht ausgeführt werden, ohne dass dieses Modul vorhanden ist. Hier sind unsere aktuellen Schritte. Meine Frage ist: Kann das einfacher und effektiver gemacht werden? Angenommen, ich entferne das Modul foo_bar.

Bereiten Sie in RCS eine neue Version vor, in der:
- Alle CSS- und Theme-Overrides, die foo_bar verwenden oder darauf aufbauen, werden entfernt.
- Alle CSS- und Theme-Overrides für Module, die von foo_bar abhängen, werden entfernt.
Schieben Sie diese Freigabe zur Annahme. Testen Sie die Deinstallation (von admin / modules) mit einer aktuellen Kopie der Produktionsdatenbank.
Wenn alles in Ordnung ist, stellen Sie die neue Codebasis für die Produktion bereit und deinstallieren Sie dort foo_bar und seine Abhängigkeiten. Dies ruft die Deinstallation in den verschiedenen Modulen auf und bereinigt die Datenbank.
Bereiten Sie in RCS (git) eine neue Version vor, in der der Code tatsächlich entfernt wird.
Setzen Sie das ein, um zu akzeptieren, dass wir testen, ob nichts versehentlich davon abhängt (einige hässliche Module oder Designfunktionen enthalten Dateien direkt von anderen Modulen. Insbesondere CSS, JS oder Bilddateien).
Wenn akzeptiert, stellen Sie eine neue Version für die Produktion bereit. Die Produktion verfügt nun über eine saubere Datenbank und eine saubere Codebasis .

Problem, das ich nicht lösen kann, ist, dass dies immer zwei Versionen benötigt. Da in Drupal ein Release erfordert, dass die Site offline ist, bedeutet dies zweimal Ausfallzeit, um nur ein Modul zu entfernen. Außerdem sind zwei Release-Verfahren erforderlich, die in professionellen Hosting-Umgebungen sehr teuer, zeitaufwändig oder frustrierend sein können.

Wenn wir das Modul in der ersten Iteration aus der Codebasis entfernen, können wir die Deinstallations-Hooks nicht ausführen, wodurch viele Flusen in der Datenbank verbleiben. nicht nur ein paar Tabellen, sondern vor allem Variablen und Gebietsschemata. Wenn wir das Modul nicht aus der Codebasis entfernen, bedeutet dies, dass die Codebasis mit veraltetem, nicht verwendetem Code wächst. Dies verursacht keinen Performance-Overhead, macht jedoch die Pflege des Codes immer schwieriger.

Wie gehst du damit um?

[edit: Hinweis hinzugefügt, dass die Bereitstellung oft ein schwieriges Verfahren ist]

nodes deployment

— Berkes
quelle

Wenn Sie die Schritte 1 bis 6 zuerst auf einem Staging-Server ausführen, können Sie dann die Live-Site nicht auf HEAD ^ aktualisieren, deinstallieren und dann auf HEAD aktualisieren (alles in einer Sitzung)?

— Andy

Wenn alle meine Projekte von Git bereitgestellt wurden, dann ja. Aber einige brauchen Tarballs, die verschickt werden müssen, während andere (nur!) FTP und so weiter verwenden. Aber es ist sicherlich eine sehr interessante Idee, sich mit Git und einigen Git-Hook-Skripten zu befassen.

— Berkes

Warum genau ist es erforderlich, die Website herunterzufahren?

— Letharion

@Letharion: 1) Durch das Entfernen der Site werden unerwünschte Schreibvorgänge in Ihre Datenbank während des Änderungsprozesses dieser Datenbank verhindert. Drupal verwendet keine Transaktionen. 2) Das Bereitstellen von neuem Code, der von einem bestimmten Datenbankstatus abhängt (ein Thema, das ein bestimmtes cck-Feld erfordert, z. B.), führt zu einer Unterbrechung Ihrer Site in der Zeit zwischen dem Rollout von Code und dem Aktualisieren der Datenbank.

— Berkes

Achten Sie sehr darauf, dass Ihre Datenbank und Ihr Code synchron bleiben. Wie Sie in Ihrer Frage erwähnt haben, müssen die zu deinstallierenden Module in der Codebasis bleiben, bis ihre Deinstallations-Hooks in der Live-Datenbank ausgeführt werden. Dies ist eine Einschränkung von Drupal, die ein Git-Pull-Workflow allein nicht lösen kann.

Ich würde empfehlen, dass Sie nicht versuchen, Ihren Prozess anzupassen, sondern nach Möglichkeiten suchen, um die Ausfallzeit für die Verarbeitung Ihrer Updates zu verringern. Ich würde empfehlen, eine Ying / Yang-Staging-Umgebung mit mehreren Standorten einzurichten , um dieses Problem zu lösen. nb Ich habe die im vorhergehenden Link enthaltenen Skripte nicht verwendet. können Sie einstellen Dinge wollen bis anders, nach der gleichen Idee , dass Sie tauschen Ihre Live - und Bühnen Websites während des Einsatzes.

Befolgen Sie weiterhin das in Ihrer Frage beschriebene Verfahren mit den folgenden Anpassungen:

ein. Synchronisieren Sie wie gewohnt von Entwickler zu Bühne (Yang). Testen Sie dies, indem Sie die zu entfernenden Module deinstallieren und anschließend den Code entfernen. Git-Workflow-Hinweise: Erstellen Sie ein Tag, oder notieren Sie sich den Hash der verschiedenen Status Ihres Codes: Alle Module vor der Deinstallation vorhanden, Codemodule entfernt, Ihre überschreibt & c. entfernt, etc. nach Bedarf. Möglicherweise werden nur zwei Referenzen benötigt.

b. Wenn der Test abgeschlossen und akzeptiert ist, bringen Sie den Code auf der Bühne (Yang) wieder in den aktuellen Zustand (Ying).

c. Bereiten Sie die Live-Site (Ying-Site) für die Aktualisierung vor, indem Sie die Möglichkeit eines Benutzers deaktivieren, Inhalte auf dem System zu ändern. In der Regel wird hier eine SQL-Aktualisierung der Berechtigungstabelle durchgeführt. Zu diesem Zeitpunkt können Benutzer weiterhin Inhalte auf der Live-Site lesen, erhalten jedoch den Fehler "Berechtigung verweigert", wenn sie versuchen, Inhalte zu aktualisieren. (Wenn Sie cool sind, können Sie möglicherweise den Handler ändern, dem die Berechtigung verweigert wurde, um einen entsprechenden Hinweis darauf zu drucken, dass die Funktion vorübergehend nicht verfügbar ist.)

d. Verschieben Sie nun die Live-Datenbank (Ying) zurück in die Stage-Datenbank (Yang), wobei die Berechtigungstabelle von der Aktualisierung ausgeschlossen wird.

e. Wiederholen Sie Schritt a. nochmal. Wenn Sie Ihre Hashtags zur Hand haben, sollte es einfach sein, den Zustand wiederherzustellen, in dem die zu entfernenden Module vorhanden sind, die Deinstallations-Hooks für die Datenbank auszuführen und dann zum Zustand des Codes zurückzukehren, in dem Ihre Elemente aus Schritt 1 zusammengeführt werden zurück in.

f. Sie können nun Ying und Yang tauschen. Passen Sie dazu Ihre Apache-Konfigurationsanweisungen an. Beachten Sie /etc/init.d/apache restart, dass in diesem Fall einige Verbindungen möglicherweise getrennt werden, /etc/init.d/apache reloadein sauberer Austausch jedoch möglich ist.

G. Das Leben ist jetzt 'Yang'; Die Berechtigungstabelle wird hier nicht geändert, sodass Benutzer Inhalte erstellen können. Wenn Sie die Schritte automatisieren, e. und f. sollte die nicht verfügbare Zeit sehr niedrig sein.

h. Drücken Sie live (Yang) zurück auf die Bühne (Ying), sowohl in Code als auch in der Datenbank - oder drücken Sie bei Bedarf von dev. Sie haben jetzt eine saubere Umgebung für Ihre nächste Iteration.

— greg_1_anderson
quelle

Ying-Yang versagt schrecklich in Schritt c. Es können nur sehr spezielle Websites verwendet werden, z. B. redaktionell gesteuerte Websites, auf die nur zugegriffen werden kann. Dies liegt hauptsächlich daran, dass nicht nur Kommentare, Knoten und dergleichen deaktiviert werden müssen, sondern auch Sitzungstabelle, Watchdog, Zähler usw. aktualisiert und beschrieben werden. Ausfallzeiten scheinen eine unglückliche, aber unvermeidliche Nebenwirkung zu sein. Allerdings ist Ying-Yang für bestimmte Websites ein sehr interessantes Konzept für die Bereitstellung.

— Berkes

Natürlich hast du recht; Wenn Sie jedoch den letzten Schritt per Skript ausführen, ist das Fenster für Ausfallzeiten oder verlorene Informationen niedrig. Wenn Sie einen Eintrag aus der Sitzungstabelle verlieren, muss sich der Benutzer erneut anmelden. Ein Zähler könnte ein wenig daneben liegen. Möglicherweise fehlt eine oder zwei Benachrichtigungen im Watchdog. Wenn dies schlimmer ist als ein kurzer Zeitraum von "Diese Site ist wegen Wartungsarbeiten nicht erreichbar", verwenden Sie auf jeden Fall die einfachere Lösung. Wenn Sie es wirklich wollten, könnten Sie versuchen, die Zähler- und Überwachungsnachrichten nach dem Tausch wiederherzustellen. Dies könnte komplizierter sein, als es sich gelohnt hat, es sei denn, info + uptime SEHR wertvoll.

— greg_1_anderson

Sie können in Betracht ziehen, die Transaktionen auf der Übergangsseite mithilfe des MySQL-Binärprotokolls zu verfolgen. Siehe dev.mysql.com/doc/refman/5.0/de/point-in-time-recovery.html . Ich zögere es, Dinge einfach zusammenzuführen, aber Sie könnten zusätzliche Counter / Watchdog-Nachrichten außerhalb des Bandes nachverfolgen. Die einfachste Möglichkeit, mit der Sitzungstabelle umzugehen, besteht darin, Anmeldungen während des Übergangs zu deaktivieren.

— greg_1_anderson

Ihr Kommentar hat mich zu einer möglichen anderen Lösung geführt: Aggregieren Sie alle hook_uninstall für ein Modul als hook_update_n () eines speziellen Moduls: uninstall.module. Auf diese Weise kann ich die Codebasis in der ersten Iteration entfernen und eine viel schnellere Deinstallation in der aktuellen Version erhalten. Könnte ein Drush-Skript sein, das diese Informationen kratzt.

— Berkes

Eine weitere Sache, die ein bisschen helfen wird. Ändern Sie Ihren gesamten benutzerdefinierten PHP-Code so, dass alle Verweise auf das zu entfernende Modul eingeschlossen sind if (module_exists('removeme')) { ... }. Stellen Sie diesen Code bereit. Wenn Sie testen und bestätigen, dass das Entfernen des Moduls Ihren benutzerdefinierten Code nicht mehr beeinträchtigt, wird die Bereitstellung vereinfacht. Es ist immer noch ratsam, den Deaktivierungsschritt auf einer Site durchzuführen, die nicht aktiv ist, aber dies wird möglicherweise Ihr Fenster etwas einschränken. Ich glaube nicht, dass Ihr benutzerdefinierter Update-Hook das Deaktivieren eines Live-Moduls sicherer macht.

— greg_1_anderson