WordPress-Seiten und Versionskontrolle

Wir sind ein Softwareentwicklungsunternehmen und verwenden WordPress für den statischen Teil der Website. Natürlich ist unser gesamter Workflow um die Versionskontrolle herum aufgebaut: mehrere Entwickler -> kontinuierliche Integration -> Staging -> Bereitstellung.

Unsere Herausforderung bei der Integration von WordPress in unseren Workflow besteht darin, dass die Datenbank wie ein Knochen im Hals stecken bleibt: Sie können sie nicht in die Versionskontrolle stecken, einfach zurücksetzen, von der Staging- zur Produktion hochstufen usw.

Ich frage mich, was Menschen in ähnlichen Situationen tun? Ich würde gerne einen Weg finden, WP in den Entwicklungsworkflow zu integrieren und nicht umgekehrt 🙂

Klärung Wir möchten Seiten auf dem Staging-System “entwickeln” und testen und sie dann als Teil des Versions-Upgrade-Prozesses in die Produktion verschieben. Wir möchten keine vollständige Replikation der Staging-Datenbank in die Produktion durchführen.

Das ist eine häufig gestellte Frage, an deren Bewältigung ich gearbeitet habe. Ich habe Code geschrieben, um diese Probleme anzugehen, obwohl der Code noch nicht zur Verteilung bereit ist. Grundsätzlich ist die Idee zu Erstellen Sie Skripts, um den Inhalt zu importieren, und führen Sie dann die Versionskontrolle der Skripts durch. (Eigentlich verwendet mein Ansatz ein benutzerdefiniertes Import-/Exportformat, das so konzipiert ist, dass es einfach von Hand geändert werden kann, aber die Idee ist ähnlich.)

Wie auch immer, es gibt einige verwandte Fragen auf der Schwesterseite von StackOverflow WordPress-Antworten:

• Mit dem Begriff getaggte Fragen [staging]
• Mit dem Begriff getaggte Fragen [deploy]

AKTUALISIEREN

Zur Klarstellung wäre dies wahrscheinlich auch hilfreich:

• Gibt es eine Möglichkeit, eine Überarbeitung einer veröffentlichten Seite oder eines Beitrags zu entwerfen? Welche Problemumgehungen haben Sie verwendet?

Hoffe das hilft.

-Mike

Ich bin gerade auf das gleiche Problem gestoßen. Im Moment verwenden wir MySQL-Dump-Dateien, um Datenbankinhalte zu exportieren/importieren, aber es wird hässlich, wenn mehrere Personen an den Datenbankänderungen arbeiten.

Da das Team, das an dem Projekt arbeitet, ausschließlich intern ist und nur aus wenigen Personen besteht, denke ich in die Richtung, die Datenbank-Dump-Datei in VCS zu sperren. Subversion hatte diese Funktionalität eingebaut, aber wir verwenden Git, was meiner Meinung nach konzeptionell das Gegenteil von jeder Art von Sperren ist.

Wahrscheinlich haben wir ein Workaround-Skript mit Pre-Commit-Hook, um zu prüfen, ob neben dem Dump eine Sperrdatei vorhanden ist. Die Person, die die Sperrdatei festgeschrieben hat, ist die einzige, die den Dump festschreiben darf. Sobald er die Arbeit beendet hat, muss er die Entfernung der Sperrdatei begehen.

Es klingt hässlich, ich weiß. Aber ich habe eine Weile darüber nachgedacht und sehe noch keine elegante Lösung.

Wenn Sie WordPress nur für statische Inhalte verwenden, sollte jedes Tool/jede Methode zur Versionskontrolle von Datenbanken funktionieren – arbeiten Sie beispielsweise die mysql-Befehlszeilentools in Ihre CI- und Bereitstellungsroutinen ein.