Projektleitlinien: Bereitstellungsumgebungen

Diese Reihe von kurzen Artikeln besteht aus einigen Dingen, die ich in den letzten Jahren bei der Durchführung von Projekten in dem Bereich gelernt habe, in dem wir tätig sind (vorausgesetzt, Sie lesen dies aus demselben Teil der Branche wie ich 🙂). Arbeit.

Wenn Sie gerade darüber stolpern, die Serie deckt einige Faktoren ab, die für ein Projekt wichtig sind :

1. Es sollte kein „ Design by Committee” geben. „
2. Niemand außer dem Kernentwicklungsteam sollte in der Lage sein, Entwicklung, Staging und Produktion bereitzustellen.
3. Niemand außer dem Entwicklungsteam sollte in der Lage sein, in die Produktion zu schreiben (und selbst dann sollte es einen Bereitstellungsprozess geben).

Ich mache solche harten und schnellen Regeln nicht wirklich gerne, weil sich die Dinge im Laufe der Zeit ändern, entweder durch Notwendigkeit oder durch mehr Erfahrung. Deshalb mag ich „Richtlinien”.

Aber zum Zeitpunkt des Schreibens dieses Artikels sind dies die Dinge, die ich sehe.

Bereitstellungsumgebungen

In den letzten Jahren haben wir große Fortschritte dabei gemacht, wie schnell wir unsere Systeme so bereitstellen können, dass sie sich alle (oder allgemein) spiegeln. Dazu gehören unsere Entwicklungsboxen, wie unsere lokalen Maschinen Staging widerspiegeln und wie Staging die Produktion widerspiegelt.

Bereitstellung einer neuen Umgebung, mehr oder weniger. Dran bleiben.

Das heißt, wenn es "funktioniert auf meiner Maschine" eigentlich wahr sein sollte. Keine Entschuldigung dafür, einen Fehler nicht reproduzieren zu können.

Und wenn es wahr ist, gilt es wahrscheinlich auch für die Maschinen anderer, für das Staging und die Produktion. Und das ist schön, oder? Ich meine, wir drehen unsere Boxen auf, stellen unsere Skripte bereit oder tun, was wir tun, und dann haben wir das Setup, das wir brauchen.

Was bedeutet es also, sich um die Bereitstellung von Umgebungen zu kümmern? Es hängt davon ab, auf welche Umgebung Sie sich beziehen.

Wie sieht das wirklich aus?

Wenn Sie in WordPress arbeiten, was ich vermute, wenn Sie dies lesen, wird davon ausgegangen, dass Sie mindestens einen Webserver, eine Datenbank und PHP ausführen.

Eine Entwicklungsumgebung kann wie folgt aussehen:

• Apache von Nginx ,
• MySQL, das am häufigsten verwendet wird,
• Mindestens PHP 5.2.4 (mit PHP 7.1 empfohlen),
• Oder etwas Vergleichbares.

Möglicherweise verwenden Sie auch etwas wie Laravel Valet oder etwas wie VVV. Es hängt alles von der Art Ihrer Arbeit ab.

Darüber hinaus haben Sie je nach Art Ihres Unternehmens möglicherweise eine IDE, die Ihnen zusammen mit verschiedenen Konfigurationsdateien zugewiesen wird, um bestimmte Regeln durchzusetzen.

Und der Rest der Umgebungen?

Wie gewöhnlich:

• Entwicklung bezieht sich auf die Einrichtung auf Ihrem lokalen Rechner,
• Staging bezeichnet den Bereich, in dem Sie und die Stakeholder testen und testen können,
• und in der Produktion befindet sich die Anwendung.

Das sieht aber auch anders aus, je nachdem, wo man arbeitet, wie man seine Arbeit organisiert und so weiter. Es geht nicht so sehr darum, wie es verwendet wird – es geht darum, dass es verwendet wird.

Inszenierung

Dies wird normalerweise auf einem Server (oder einer Gruppe von Servern, je nach Größe des Projekts) bereitgestellt, auf dem Sie Ihren neuesten Code zum Testen bereitstellen können. Es kann Teilfunktionen, Testdaten und nur eine Teilmenge von Informationen aus der Produktionsumgebung enthalten (wenn Sie sich dafür entscheiden, diese Informationen, nämlich die Datenbank, aus der Produktionsumgebung abzurufen).

Dies gibt Ihnen und den anderen Beteiligten die Möglichkeit zu überprüfen, was ausgegeben wird und wie es in der Produktion funktionieren wird, ohne sich Gedanken über die Zerstörung sensibler Daten machen zu müssen.

Der Code wird normalerweise von einem Zweig, normalerweise Master, aus Ihrem Git-Repository bereitgestellt (falls Sie das verwenden). Und Tools wie DeployBot, CircleCI, Travis CI, GrumPHP, Behat usw. werden ebenfalls verwendet, um sowohl die Codequalität zu bewerten, automatisierte Tests durchzuführen und schließlich den Code bereitzustellen.

Am Ende wird jede Umgebung so bereitgestellt, dass sie schnell auf lokalen Computern, den Staging-Servern und den Produktionsservern gespiegelt werden kann. Darüber hinaus sollte es einfach sein, Daten zwischen ihnen zu verschieben und zu ziehen, um die Arbeit mit den Daten zu vereinfachen.

Produktion

Schließlich dreht sich bei der Produktion alles um das eigentlich funktionierende Projekt; Dies bedeutet, dass der Server, die Anwendung und die Datenbank in Verbindung miteinander ausgeführt werden und von Benutzern verwendet werden.

Dies bedeutet auch, dass der Code an einem stabilen Ort ist. Es gibt wahrscheinlich Protokollierungsmechanismen, die das Entwicklungsteam über Probleme informieren. In dieser Umgebung sollte keine Änderung des Codes erfolgen, ohne dass dieser zuerst die QA oder das Staging bestanden hat.

Und die bestehenden Prozesse?

Okay, nehmen wir an, Sie arbeiten mangels eines besseren Begriffs mit einem herkömmlichen Setup, bei dem alle Ihre Bereitstellungen über S/FTP in einer Produktions- (oder sogar Staging-) Umgebung erfolgen. Auf diese Weise können Benutzer Dateien herunterziehen, Änderungen vornehmen und sie wieder nach oben verschieben.

Das ist nicht gut.

Das bedeutet, dass sich jeder mit den Anmeldeinformationen anmelden, die Änderungen vornehmen und die Quellcodeverwaltung, kontinuierliche Integration, Qualitätssicherungstools usw. umgehen und alle gewünschten Änderungen vornehmen kann.

Es untergräbt die gesamten eingerichteten Prozesse. Dieses Verfahren umgeht nicht nur das Standardverfahren (das natürlich aus einem bestimmten Grund vorhanden ist), sondern führt auch dazu, dass der Code beschädigt wird, den ein Entwickler oder ein Entwicklerteam auf seinen Computern hat, hauptsächlich weil das, was in der Produktion ist, nicht mehr mit dem synchron ist Code-Repository.

Darüber hinaus könnte dieser Code auf Zweige verteilt werden, die noch zusammengeführt oder bereitgestellt werden müssen. Dies lässt uns mit einer Vielzahl von Situationen zurück, in denen Entwickler und Kunden einen Teil des Build-Prozesses und damit das gesamte Projekt unterbrochen haben.

Wenn es an der Zeit ist, die Produktion zu überprüfen, ist sie nicht synchron mit Entwicklung und Staging, und niemand weiß warum. Wenn es Zeit für die Bereitstellung ist, werden die Änderungen überschrieben, und die Verantwortlichen haben verloren, was sie zu sehen glaubten.

Was ist ein Team zu tun?

Ich weiß nicht, ob es darauf eine richtige Antwort gibt, aber je länger ich in dieser Branche arbeite, desto mehr glaube ich, dass die Firma – oder Firmen – die für die Entwicklung der Lösung für den Kunden verantwortlich sind, die Kontrolle über den Prozess von Anfang an haben sollte. beenden.

• Designer sind dafür verantwortlich, ihre Bereiche zu verwalten, Konzepte zu erstellen, Mocks zu erstellen, Demo-Vorlagen zu erstellen und Feedback einzuholen.
• Projektmanager sind verantwortlich für die Kommunikation mit den Abteilungen,
• Entwickler sind verantwortlich für die Implementierung der Lösung und die Verknüpfung der Arbeit der Designer mit dem funktionalen Back-End.
• Der Kunde ist dafür verantwortlich, Änderungen zu überprüfen, Feedback zu geben und alle anderen Informationen bereitzustellen, die zum Abschließen der Aufgabe erforderlich sind.

Das bedeutet, dass das Einrichten der Domain, des Hostings, der Umgebungen, der Versionskontrolle, des Build-Prozesses und der kontinuierlichen Integration und alles andere, was ich vernachlässigt habe, direkt dem Entwicklungsteam obliegt.

Bleiben Sie in den Schützengräben, bleiben Sie am Ziel (aber achten Sie auf die Menschen um Sie herum).

Einfach ausgedrückt, sind dies nicht die Verantwortlichkeiten des Kunden und sollten es auch nicht sein. Verantwortungsgrenzen sollten in allen Teams festgelegt, gepflegt und respektiert werden – nicht nur Entwickler und Kunden oder Kunden und Designer oder Designer und Entwickler und so weiter.

Was kommt als nächstes?

Im nächsten Beitrag werde ich über die Verantwortlichkeiten sprechen, die Entwickler (und andere Beteiligte) bei der Pflege von Umgebungen für den Code haben.

Das heißt, wer sollte für was verantwortlich sein und wer darf welche Daten lesen und schreiben und wie sich dies letztendlich auf das Ergebnis des Projekts auswirken kann.