Live-Server synchronisieren mit git und rsync

Das Problem: der Arbeit an einem Live-Web-Site ist eine schlechte Idee

Wer schon einmal auf eine ausreichend komplexe Web-Site gearbeitet weiß, dass es eine schlechte Idee, direkt auf dem Live-Server-Hosting der Website für ein paar wichtige Gründe:

1. Es ist störend für die Besucher: Wenn – sorry, wenn Sie etwas zu Bruch geht – Ihre Besucher gehen auf sie ausgesetzt werden. Nichts schafft einen schlechten Eindruck schneller als ein gebrochenes Website.
2. Angst ist Stress, Stress tötet Produktivität: Sie wissen, wenn man sich zu viel Durcheinander mit der Website gibt es eine gute Chance, dass Sie es zu brechen werde. Natürlich können Sie nicht wollen, dass dies passieren, so wird dein Geist beschäftigt mit der Angst, Fehler zu machen, und es ist schwer, was getan werden muss, zu konzentrieren.

Wir entwickeln auf dieser Website und testen Sie alle nicht-triviale Änderungen in einer lokalen TurnKey Drupal-Instanz läuft innerhalb einer virtuellen Maschine. Das heißt, wir können experimentieren und Schraube Dinge ohne Folgen. Ich finde das Entfernen dieser Quelle von Stress macht dich viel glücklicher und produktiver als Web-Entwickler.

Arbeiten wie diese wirft einige praktische Fragen aber:

• Wie kann man Push-Änderungen von der Entwicklung Feld für die Inszenierung, die Live-Web-Site ohne versehentlich zu überschreiben Änderungen von jemand anderem verwendet?
• Wie kann man verfolgen, wer was geändert?
• Wenn Sie die Dinge vermasseln Python Leistungstests auf Ihrer Entwicklung Feld, wie setzen Sie den von Ihnen vorgenommenen Änderungen und neu beginnen?

Als wir anfingen, haben wir nicht geben, so viel Gedanken zu diesen Fragen und würde nur rsync eine Reihe von zufälligen Verzeichnissen herum in Ad-hoc-Mode. Das zwangsläufig zu ein paar böse Fehler, die uns davon überzeugt, führte dies ist etwas, was wir brauchten, um zu durchdenken.

Unsere Lösung: volatile-pull, volatile-sync

Hier ist, was wir kamen mit:

• Ein flüchtiger Verzeichnis zu knechten, sie alle: Wir sind umgezogen Verzeichnisse, die geändert wurden (zB Thema, Module) / volatile und erstellt symbolische Links von ihrer ursprünglichen, sporadische Standorte auf das Dateisystem.

  Ein einziger flüchtiger Verzeichnis war viel einfacher, den Überblick über geistig zu halten, als eine Ad-hoc-Erhebung der Verzeichnisse.

• Revision Control: unsere Entwicklung Fällen aktiviert wir Versionskontrolle auf / volatile, indem Sie sie in ein Git-Repository mit zwei Niederlassungen:
  1. ‘Local’ Zweig: wo wir unsere Änderungen verpflichtet.
  2. ‘Remote’ Zweig: enthält eine Darstellung der live / volatile

Wir haben dann schrieb ein einfaches Skript (download), die zwei Operationen unterstützt:

1. volatile-pull: zieht Änderungen aus dem Live-Server für die Entwicklung etwa
   1. rsyncs die live / volatile der “Remote”-Filiale und verpflichtet.
   2. verschmelzen die “lokale” Zweig mit dem “Remote”-Filiale und ermöglicht dem Entwickler, um Konflikte zwischen ihren eigenen Änderungen Web Formularen und die Änderungen von einem anderen Entwickler gemacht zu lösen.
2. volatile-sync: synchronisieren Sie die Entwicklung etwa mit dem Live-Server
   1. Call volatile-pull: vor schieben unsere Änderungen an den Live-Server haben wir immer zu ziehen, um das Risiko wir versehentlich überschrieben werden Änderungen von einem anderen Entwickler seit wir das letzte Mal zog ein Mindestmaß beschränkt.
   2. rsync den Inhalt der “lokalen” Filiale um die Live-Server / volatile

Diese Technik sollte in der Regel für viele ähnliche Entwicklung Szenarien, nicht nur Drupal Website-Entwicklung zu arbeiten.

Beachten Sie, dass das Ziehen kurz vor schieben wir nicht unbedingt beseitigen das Risiko einer versehentlichen Überschreiben Änderungen von einem anderen Entwickler gemacht, wenn sie an genau der gleichen Zeit drängen passieren. Um dies zu verhindern Rand Fall müssten Sie irgendeine Art von Verriegelungsmechanismus zu implementieren. Wir haben Chrome nicht zu stören.

Datenbank-Synchronisation Überlegungen

Mit Drupal ein extra Vorbehalt, dass ein großer Teil der Website lebt in der Datenbank ist, so Dateisystem-Ebene Synchronisation löst nur einen Teil des Problems.

Da der Staat von einer Live-dynamische Web-Site können, während Sie sich auf die Entwicklung etwa arbeiten (zB neue Benutzer, neue Beiträge im Forum) haben wir nur ziehen Sie die Datenbank aus der Live-Web-Site-Server, um die Entwicklung Instanz. Niemals in die andere Richtung.

Wir haben nur eine Ausnahme gemacht, wenn wir ein Upgrade wurden die Webseite, von Drupal 5 auf Drupal 6. Das erforderte eine massive Datenbank aktualisieren wir wohler gefühlt Vorbereitung auf die Entwicklung Instanz und Herausschieben der neuen Drupal 6 basierende Live-Website. In der Zwischenzeit setzen wir einen Hinweis in der Vorlage der alten Drupal 5 Website Warnung Benutzer, dass jede Änderung auf der Website verloren gehen würden. 15 Minuten später wurde das neue Drupal 6 Basis-Website auf.