Share
In dieser Serie werfen wir einen Blick auf die verschiedenen Vorgehensweisen, die in der professionellen WordPress-Entwicklung verwendet werden. Im vorigen Artikel haben wir eine Reihe von Strategien und Referenzmaterial vorgestellt, die beim Erstellen von Themen, Plugins und WordPress-basierten Anwendungen hilfreich sind.
In diesem Artikel werden die Versionskontrolle und die Umgebungskonfigurationen beschrieben, die es uns erleichtern, unsere Arbeit zu entwickeln, zu testen und einzusetzen, um die Anzahl der Fehler zu minimieren, die in die endgültigen Versionen unserer Arbeit gelangen.
Dieses Thema ist nichts Neues. Tatsächlich würde ich sagen, dass die Mehrheit der Leser hier mit Subversion und / oder Git (insbesondere mit der Beliebtheit von GitHub) vertraut ist. In diesem Artikel geht es also nicht so sehr darum, einen Überblick über die verschiedenen Quellcodeverwaltungssysteme zu geben oder einen Fall darzulegen, für den Sie einen Einsatz machen sollten Warum Sie sollten die Quellcodeverwaltung verwenden und wie sie mit unserer Umgebung zusammenhängt.
Wenn du bist vollständig Neu im Konzept der Versionskontrolle, lassen Sie uns eine einfache Definition angeben, von der aus wir arbeiten können, damit wir alle auf derselben Seite sind:
Die Versionskontrolle ist eine Momentaufnahme Ihres Quellcodes zu einem beliebigen Zeitpunkt, mit der Sie ein Rollback durchführen können, wenn ein Fehler auftritt, und an einer neuen Funktion arbeiten, ohne den vorhandenen Code zu beschädigen.
In der WordPress-Community sind die Menschen oft unschlüssig, ob sie über Themen und / oder Plugins oder über verherrlichte Websites nachdenken. Ich persönlich glaube, dass sie eine Form von Software sind, da sie den gleichen Praktiken unterliegen:
Zu diesem Zweck sollte die Entwicklung und Pflege von WordPress-spezifischen Arbeiten als solche behandelt werden und es ist Industriestandard, um eine Versionskontrolle für Software zu gewährleisten.
Darüber hinaus arbeitet die Versionskontrolle Hand in Hand, indem Sie an Ihrem Projekt arbeiten, es testen und dann auf einem Live-Server bereitstellen, der von anderen verwendet werden kann.
Die meisten Entwickler sind mit den verschiedenen Umgebungen vertraut, auch wenn sie nicht die genaue Terminologie verwenden. Einfach definiert:
Einfach genug.
Die Sache ist, dass jede dieser Umgebungen auch eng mit der Versionskontrolle zusammenhängt, sodass Sie bei korrekter Verwaltung den Aufwand für die Verwaltung von Versionen und Bereitstellungen Ihrer Arbeit minimieren können.
Die Entwicklungsumgebung ist die Maschine, auf der Sie Ihr Projekt tatsächlich entwickeln. Es enthält eine Kopie von WordPress, des Webservers, des Datenbankservers, der IDE und der zugehörigen Tools, die Sie zum Erstellen Ihres Projekts verwenden.
In dieser speziellen Umgebung sollten Sie häufige Commits ausführen. Damit meine ich, dass Sie jedes Mal, wenn Sie eine bedeutende Änderung vornehmen - sei es eine neue Funktion, eine Fehlerbehebung oder ähnliches - dann sollten Sie dem Repository Code übergeben.
Der Vorteil ist hier, dass Sie problemlos Änderungen rückgängig machen, identifizieren und zwischen Änderungen unterscheiden können, falls während des Prozesses etwas schief geht.
Wenn Sie eine große Anzahl von Änderungen abgeschlossen haben (wo Sie oder Ihr Team feststellen, was als "signifikant" bezeichnet wird), ist es an der Zeit, die Änderungen zu markieren und in der Staging-Umgebung bereitzustellen.
Die Staging-Umgebung ist ein separater Server, der der Produktionsumgebung ähnelt. Er wird jedoch zum Testen des Projekts vor der Veröffentlichung verwendet. Es enthält die neueste Version des Codes sowie Testdaten und ist für Benutzer gedacht, um das Projekt vor der Veröffentlichung auszuwerten. Hier sollte keine Entwicklung stattfinden.
Obwohl hier keine Entwicklung stattfinden sollte, ist es nicht ungewöhnlich, dass verschiedene Debugging-Tools vorhanden sind, um Protokollnachrichten zu generieren oder zu überprüfen, was in der Datenbank während der Arbeit an der Site passiert und aus ihr herauskommt.
Da Entwickler häufig Änderungen an dem Repository vornehmen, müssen sie getestet werden. Hier kommt die Staging-Umgebung ins Spiel. Im Allgemeinen entspricht die Staging-Umgebung häufig dem, was die letzten Änderungen an dem Repository vorgenommen haben.
Dies wirft jedoch zwei Fragen auf:
Zunächst einmal ist das eine gute Sache - das bedeutet, dass die Inszenierungsumgebung ihren Zweck erfüllt hat! Außerdem haben wir die Möglichkeit, unseren Quellcode zu überprüfen, um festzustellen, ob ein Fehler behoben werden muss oder eine neue Funktion eingeführt werden sollte.
Und hier ist die Quellcodeverwaltung hilfreich.
Wenn ein Fehler aufgetreten ist, lehnen Sie sich möglicherweise in die Richtung zurück, in der die Änderung rückgängig gemacht wird. Dies ist jedoch in der Staging-Umgebung nicht erforderlich. Stattdessen ermitteln Sie einfach, wo sich der Fehler befindet, beheben ihn, legen den Code fest und implementieren ihn dann zum Testen erneut in der Staging-Umgebung.
Sie wiederholen diesen Vorgang, bis keine Fehler vorhanden sind oder genauer, Sie können keine Fehler finden.
Wenn Sie keine Fehler finden können, haben Sie im Wesentlichen das, was als stabiler Build bezeichnet wird. An dieser Stelle können Sie eine Version Ihres Codes mit Tags versehen oder stempeln, kennzeichnen oder was auch immer Ihr Quellcodeverwaltungssystem anbietet, und diese in der Produktionsumgebung bereitstellen.
Natürlich besteht die Möglichkeit, dass ein Fehler entdeckt wird, nachdem er in der Produktionsumgebung bereitgestellt wurde. In diesem Fall sollten besondere Maßnahmen ergriffen werden.
Die Produktionsumgebung ist gleichbedeutend mit der Live-Site. Hier erstellen, verwalten und interagieren tatsächliche Benutzer mit tatsächlichen Daten. Hier sollte keine Entwicklung stattfinden.
In Bezug auf die Entwicklung gibt es kaum etwas über die Produktionsumgebung zu sagen. Schließlich sollte dies nichts anderes als der Ort sein, an dem Quellcode für andere Benutzer bereitgestellt wird.
Es besteht jedoch die Möglichkeit, dass hier ein Fehler veröffentlicht wird. Wenn das passiert, diese ist, wenn ein Rollback erfolgen soll. Einfach ausgedrückt, ein Rollback ist, wenn Sie die neuesten Änderungen vornehmen und die Bereitstellung buchstäblich rückgängig machen, wodurch das Projekt in seinem vorherigen Zustand wiederhergestellt wird.
Bevor Sie ein Rollback durchführen, sollten Sie alle Schritte zur Wiederherstellung beachten, damit Sie sie sowohl in der Staging-Umgebung als auch in der Entwicklungsumgebung reproduzieren können, um das Problem ordnungsgemäß zu lösen.
Führen Sie von hier aus die Entwicklung aus, die zur Behebung des Problems erforderlich ist, nehmen Sie eine weitere Änderung vor, stellen Sie sie in der Staging-Umgebung bereit und stellen Sie sie in der Produktionsumgebung bereit, vorausgesetzt, dass die Tests bestanden wurden.
Offensichtlich deckt dieser spezielle Beitrag Konzepte auf hoher Ebene ab: Wir untersuchen nicht, welche Versionskontrollsysteme am besten geeignet sind, und wir prüfen nicht, welche Tools für Ihr spezielles Betriebssystem am besten geeignet sind. Diese Themen liegen außerhalb des Rahmens dieses Beitrags und verdienen jeweils ihre eigene Serie.
Im Rahmen der Professional WordPress-Entwicklung können sich diese Vorgehensweisen jedoch bei der Entwicklung, beim Testen und beim Bereitstellen (und Zurücksetzen) von Versionen Ihres Projekts als nützlich erweisen.
In dem letzten Beitrag werden wir uns einige der verschiedenen verfügbaren Tools ansehen, die es uns ermöglichen, viele Fehler in unserer lokalen Entwicklungsumgebung zu diagnostizieren, um zu verhindern, dass viele von ihnen sogar die Staging-Umgebung erreichen.
Accentsconagua