web-dev-qa-db-de.com

Wordpress Git Workflow-Hilfe

Ich suche eine stark optimierte Workflow-Idee für die Arbeit mit Wordpress.

  1. Ich möchte meine Git-Umgebung intern auf meinem eigenen Server haben, ohne Github für die Verwaltung von Repos zu verwenden.
  2. Automatische Erstellung von Subdomains bei der Erstellung von Git-Zweigen (development.domain.com, ryan.development.domain.com) - Möglicherweise sind einige Shell-Skript-Hooks dafür ideal.
  3. Phing PHP/Shell-Skript Handhabung der Datenbankmigration (so ähnlich http://interconnectit.com/products/search-and-replace-for-wordpress-databases/ ), um das Ersetzen der serialisierten Datenbank beim Push zu handhaben

Die Operation würde wahrscheinlich in etwa so ablaufen:

  1. abrufen der aktuellsten WordPress-Version und Verzweigen, Name der Verzweigung erhält einen Subdomain-Eintrag (branchdevelopment.domain.com)
  2. modulieren Sie das gewünschte Thema, wenn es verfügbar ist (ich möchte dafür mein eigenes Git-Repo erstellen, da ich eine These verwende. Ich möchte ein leeres Git-Repo-Setup für die Arbeit haben, das intern auf dem bereits erstellten Server abgerufen werden kann.)
  3. auschecken und Änderungen vornehmen, Client-Überprüfungen durchführen, sobald es veröffentlicht wurde, wird das Datenbankskript automatisch gestartet, um die serialisierten URL-Werte von localhost (oder Subdomain) in die Live-URL zu ändern

Ist das möglich? Ich habe gehört, dass Capistrano auch gut damit zu nutzen ist, bin mir aber nicht sicher, wie Capistrano vollständig funktioniert.

Ich betreibe ungefähr 200 Sites auf meinem eigenen Server und möchte diese Sites in einer starken Git-Workflow-Umgebung implementieren, damit ich meine Arbeit viel besser rationalisieren kann. Ab sofort lade ich im Grunde genommen ein Image der Site herunter und bearbeite es lokal. Anschließend lade ich die Änderungen zurück auf den Server. Das ist heutzutage sehr mühsam.

Hat jemand eine Lösung für diese Art von Workflow/hat er in der Vergangenheit damit gearbeitet? Wenn ja, wären einige Ressourcen/Antworten sehr dankbar.

16
Ryan Dennler

Allgemeine Fragen beantwortet

Nr.1. Ich möchte meine Git-Umgebung intern auf meinem eigenen Server haben, ohne Github für die Verwaltung von Repos zu verwenden.

Das erste, was ich tun würde, wäre, composer und die Funktionsweise von WordPress zu untersuchen, einem Projekt von Andrey "@Rarst" Savchenko .

Nr.2. Automatische Erstellung von Subdomains bei der Erstellung von Git-Zweigen (development.example.com, ryan.development.example.com) - Wahrscheinlich sind einige Shell-Skript-Hooks dafür ideal.

Dies ist etwas außerhalb des Bereichs für diese Site. Bitten Sie entweder um Hilfe bei StackOverflow oder fragen Sie Ihren Hoster. Einige Hoster erlauben es nicht, diese Einträge selbst zu bearbeiten.

Nr.3. Phing PHP/Shell-Skript Behandlung der Datenbankmigration (so ähnlich wie dieses http://interconnectit.com/products/search-and-replace-for-wordpress-databases/ ), um das Ersetzen der serialisierten Datenbank zu handhaben schieben

Ich würde eine Multisite-/Netzwerkinstallation einrichten. Auf diese Weise können Sie alle Tabellen einfach verwalten, die Benutzer an einem zentralen Ort aufbewahren usw.

WP Gear - ein Projekt von Robert "@Wyck" Ellison - enthält eine Liste alternativer Erstellungsskripte. Einschließlich WordPhing , das er selbst geschrieben hat. @TomJNowells /Interconnect.it script ist noch nicht in dieser Liste enthalten.

Operationsfragen beantwortet

Nr. 1. Holen Sie sich die aktuellste WordPress-Version und verzweigen Sie sie. Der Name des Zweigs erhält einen Subdomain-Eintrag (branchdevelopment.domain.com).

Ich bin mir nicht sicher, warum ich das tun möchte: Eine Unterdomäne für jeden Zweig. Wenn Sie sich das synchronisierte WordPress GitHub-Repository und die -Liste der Zweige ansehen, werden Sie feststellen, dass jeder Zweig den Namen X.Y-branch trägt. So würden Ihre Subdomains beispielsweise nach 3.6-branch. Ich bin mir nicht sicher, ob eine Subdomain mit einer Ziffer beginnen darf (sollte es sein, aber fragen Sie Ihren Hoster), und dann gibt es das Problem, dass Sie eine Sub-Subdomain mit dem Namen 6-branch erhalten, die eine Sub-Sub-Subdomain hat benannter 3 und ein anderer benannter 2. Und raten Sie, dass Pairing Zweige mit zwei und drei Versionen in einer Unterdomäne nicht das sind, was Sie erreichen möchten.

Kurz gesagt: Nur checkout 3.6-branch, wenn Sie die Filiale wechseln müssen.

Nr.2. submoduliere das gewünschte Theme, wenn es verfügbar ist (ich möchte dafür mein eigenes Git-Repo erstellen, da ich diese These verwende. Ich hätte gerne ein leeres Git-Repo-Setup für die Arbeit, das ich intern auf dem Server abrufen kann, der bereits vorhanden ist erstellt worden)

Thomas "@toscho" Scholz hat ein Nice-Plugin geschrieben, mit dem wir eine Subdomain verwenden können, um Themen außerhalb des WordPress-Verzeichnisses zu bearbeiten. Sie finden es sowohl in dieser Antwort als auch in dieser . Sogar automatische Updates funktionieren für Themes seit WP 3.6.

Sie können dasselbe für MU-Plugins und Plugins tun, indem Sie einfach die folgenden Konstanten in Ihrer wp-config.php -Datei festlegen:

define( 'WP_PLUGIN_DIR',   'path/to/your/plugins.dev/folder/plugins' );
define( 'WP_PLUGIN_URL',   'https://plugins.dev/plugins' );
define( 'WPMU_PLUGIN_DIR', 'path/to/your/plugins.dev/folder/mu-plugins' );
define( 'WPMU_PLUGIN_URL', 'https://plugins.dev/mu-plugins' );

Stellen Sie nun einfach alle Ihre Plugins und Themes unter Versionskontrolle und schieben Sie sie auf Ihren Server. Sie können sie ganz einfach mit mu-Plugins oder Standard-Plugins, die über das Netzwerk aktiviert werden, verfügbar machen.

Nr.3 checkout und Änderungen vornehmen, Kundenbewertungen, sobald es veröffentlicht wurde, wechselt das Datenbankskript automatisch die serialisierten URL-Werte von localhost (oder Subdomain) zur Live-URL

Wenn Toms Skript/Plugin Ihnen bisher nicht weiterhilft, wird mitgeteilt, dass er Pull-Anfragen auf GitHub akzeptiert.

6
kaiser

Keine Zeit, eine Antwort mit allen Funktionen zu schreiben (ich kenne mich irgendwie lahm aus), aber es lohnt sich wahrscheinlich trotzdem, sie zu teilen (ich könnte sie bearbeiten, weil ich auch einen Blog-Beitrag dazu plane):

Das heißt, Sie können einige trunk/version-branch-basierte WP Setups haben, die Sie vollständig hacken können, inkl. Themen und Plugins.

Da dies ein unabhängiges (lokales) Repository ist, können Sie dies per ssh auf andere Repositorys übertragen, zum Beispiel eines:

  • Das befindet sich auf dem Remote-Host, auf dem die Site bereitgestellt werden soll (Bare Repo).
  • Das hat Haken, um ein anderes Repository auf diesem Host tatsächlich in den Änderungen zusammenzuführen, die Sie gerade gepusht haben.

Dies wird in Ein web-fokussierter Git-Workflow (Nov 2008; von Joe Maller) beschrieben.

Wenn Sie dann einen Konfigurationsumschalter haben, der den konkreten wp-config.php basierend auf dem System auswählt, auf dem er ausgeführt wird, können Sie sogar alle Hosts (Entwicklung, Live, Staging, Freunde, ...) im Repo zentral konfigurieren.

Upstream-Änderungen in WP werden nur abgerufen und im Teilbaum zusammengeführt.

Plugins, die Sie nur aktualisieren und festschreiben.

Die Bereitstellung ist ein einfacher $ git Push remote.

Führen Sie auf dem Remote-Host tägliche Sicherungen für die Git-Repos, die Datenbank und die hochgeladenen Dateien durch. Dies ist kostengünstig, entwicklerfreundlich und flexibel. Dies funktioniert sowohl für Einzelentwickler-Setups als auch für kleine Teams, da jeder von der Reproduktion auf der Fernbedienung auschecken kann.


Es gibt einige Einschränkungen:


Nun mit Ihrer Checkliste und dem oben beschriebenen Setup:

1. Ich möchte meine Git-Umgebung intern auf meinem eigenen Server haben, ohne Github für die Abwicklung von Repos zu verwenden.

Github kümmert sich hier nur um Upstream-Repos (Wordpress), nicht um Ihre eigenen.

2. Automatische Erstellung von Subdomains bei der Erstellung von Git-Zweigen (development.domain.com, ryan.development.domain.com) - Möglicherweise sind einige Shell-Skript-Hooks dafür ideal.

Das beschriebene Setup ist ein modularer Ansatz mit einem Repo pro Site. Es können beliebig viele Entwicklungshosts verwaltet werden. Bei einer Installation mit mehreren Standorten können auch mehrere Domänen verwaltet werden. Bei diesem Ansatz zählt dies jedoch als ein einziges WordPress-Setup.

3. Phing PHP/Shell-Skript Handhabung der Datenbankmigration (so ähnlich http://interconnectit.com/products/search-and-replace-for-wordpress-databases/ ), um das Ersetzen der serialisierten Datenbank beim Pushen zu handhaben

Dies wird hier nicht benötigt, da nur der Code der Versionskontrolle unterliegt. Die Datenbanken sind unabhängig von Entwicklung (, Staging) und Produktion, wie es sein sollte.

Möglicherweise suchen Sie nach einem Installationsskript, das die Domänenmigration ordnungsgemäß ausführt, aber selbst mit besserem Code (der verfügbar ist) für das Suchen und Ersetzen serialisierter Daten ist dies in dieser Konfiguration normalerweise nicht erforderlich, da Sie die Änderungen nur zum Leben erwecken Für die Testfälle können Sie den Inhalt schnell in der Entwicklungsdatenbank erstellen, was normalerweise das kleinste Problem ist (aus meiner praktischen Erfahrung können Sie davon abweichen, aber ich würde auch vorschlagen, solche datenbankmigrationsbezogenen Themen bei Fragen der Datenbank beizubehalten) eigene hier vor Ort - aber bitte fragen Sie sie).

Ich betreibe ungefähr 200 Sites auf meinem eigenen Server und möchte diese Sites in einer starken Git-Workflow-Umgebung implementieren, damit ich meine Arbeit viel besser rationalisieren kann.

Ich kann mir nicht vorstellen, wie diese Websites in einer Workflow-Umgebung mit Stringgits entstehen würden. Möglicherweise werden die Konfigurationsskripte und Konfigurationsdaten, die Sie hier verwalten, unter der Versionskontrolle von Git aufbewahrt. Das könnte Sinn machen. Ansonsten halte ich es angesichts der schieren Anzahl von Websites für überhaupt keinen Sinn, alle in einem Git-Repo zu halten. Vielleicht nicht einmal einer von denen, weil das, was ich oben skizziert habe, für Sites ist, die Sie entwickeln (einschließlich des WP Kerncodes), nicht nur für Installationsaufgaben. Sie müssen sich also wahrscheinlich zuerst eine kleine Karte dieser 200 Sites erstellen und wie sie miteinander interagieren und aus welchen Paketen (WP Core, Plugins, Themes) diese Sites bestehen. Als Erstes könnten Sie eine Tabelle/Matrix erstellen und alle Websites einfügen.

Sie können es dann als CSV-Datei speichern, der Versionskontrolle unterstellen und die Bereitstellungsskripte auf der Grundlage dieser Datei ihre Arbeit erledigen lassen.

Und wenn ich bei der Automatisierung von Aufgaben etwas gelernt habe: Befolgen Sie die Unix-Philosophie, verwenden Sie die vorhandenen und gut funktionierenden Tools (es ist besser, einen halben Tag mit dem Lesen einiger Befehle zu verbringen, als nach Alternativen zu suchen, da bei den meisten Jobs die Probleme aufgetreten sind bereits gelöst) und konzentrieren sich auf Kommandozeilen-Tools. Sie sind am mächtigsten.

3
hakre