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 ist ein Shell-Skript-Hook dafür ideal.
3. Phing PHP / Shell-Skript Handhabung der Datenbankmigration (so etwas wie http://interconnectit.com/products/search-and-replace-for-wordpress-databases/ ), um das Ersetzen der serialisierten Datenbank beim Push- Vorgang 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, wechselt das Datenbankskript automatisch die serialisierten URL-Werte von localhost (oder Subdomain) zur Live-URL

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.

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, ist, den Komponisten und seine Funktionsweise mit 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) - Möglicherweise ist ein Shell-Skript-Hook dafür ideal.

Dies ist etwas außerhalb des Bereichs für diese Site. Entweder um Hilfe bitten , auf Stackoverflow oder bei Ihrem Hoster fragen. Einige Hoster erlauben es nicht, diese Einträge selbst zu bearbeiten.

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

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 Build-Skripte. Einschließlich von ihm selbst geschriebenes WordPhing . Das Skript @TomJNowells /Interconnect.it 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 Zweiges 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 benannt ist X.Y-branch. So würden Ihre Subdomains zum Beispiel benannt werden 3.6-branch. Ich bin 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-branchSub-Sub-Subdomain erhalten 3und ein anderer namens 2. Das Pairing von Zweigen mit zwei und drei Versionen in einer Unterdomäne ist nicht das, was Sie erreichen möchten.

Kurz gesagt: Nur checkout 3.6-branchwenn Sie die Filiale wechseln müssen.

Nr.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.)

Thomas "@toscho" Scholz hat ein nettes Plugin geschrieben, mit dem wir eine Subdomain verwenden können, um Themen außerhalb des WordPress-Verzeichnisses zu bearbeiten. Sie können es in finden diese Antwort sowie in diesem einen . 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.phpDatei 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 übertragen 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 Auschecken und Änderungen vornehmen, Client-Überprüfungen, 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, werden Sie darauf hingewiesen, dass er Pull-Anfragen auf GitHub akzeptiert .

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

• Ich klone Wordpress von Github (Sie können dies sogar für den Quelltext-Baum von hier aus tun: tierra / wordpress )

• Ich benutze es dann als über einen Teilbaum zusammenführen in meinen eigenen Sites Repo (Ich habe sogar einen Fehler in Git ausgeführt, aber die Lösung ist hier: -X Teilbaum = ... ).

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

Da dies ein unabhängiges (lokales) Repository ist, können Sie dies per ssh auf andere Repositorys übertragen, zum Beispiel auf 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 (November 2008; von Joe Maller) beschrieben .

Wenn Sie dann einen Konfigurationsumschalter haben, der den Beton wp-config.phpbasierend auf dem System auswählt , auf dem er ausgeführt wird, können Sie sogar alle Hosts (Entwicklung, Live, Staging, Freunde, ...) innerhalb des Repos zentral konfigurieren.

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

Plugins, die Sie nur aktualisieren und festschreiben.

Die Bereitstellung ist einfach $ 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:

• Die git-Aliase git accept-theirsund git accept-theirssind hilfreich, wenn widersprüchliche Grundlinienänderungen vorliegen, von denen Sie eindeutig wissen, mit welcher Sie sich am liebsten befassen. Sie finden das hier: Einfaches Tool, um ihre oder meine Dateien mit git für eine ganze Datei zu akzeptieren
• Hallo Dolly. Der Fluch einer ganzen Generation. Sie müssen es immer rm.

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 eines Git-Zweigs (development.domain.com, ryan.development.domain.com) - Möglicherweise ist ein Shell-Skript-Hook dafür ideal.

Das beschriebene Setup ist modular aufgebaut und umfasst ein 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 etwas wie http://interconnectit.com/products/search-and-replace-for-wordpress-databases/ ), um das Ersetzen der serialisierten Datenbank nach dem Push 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äß durchführt, aber selbst mit besserem Code (der verfügbar ist), der sich mit dem Suchen und Ersetzen serialisierter Daten befasst, ist dies in dieser Konfiguration normalerweise nicht erforderlich, da Sie die Änderungen lediglich zum Leben erwecken Für die Testfälle können Sie den Inhalt in der Entwicklungsdatenbank schnell 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 Umgebung mit String-Git-Workflows aussehen 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 an 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.