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