Frontend-Architektur im Maßstab für große Organisationen

(Daniel Ostapenko) (Daniel Ostapenko) 14. Oktober 2020)

Hallo! Ich möchte mit Ihnen diskutieren, wie die Frontend-Architektur in großen Organisationen verwaltet wird. Ich habe das Gefühl, dass es nicht viele Artikel zu diesem Thema gibt und es nicht gut erklärt wird.

Mit großer Organisation in diesem Artikel meine ich Unternehmen, in denen die Anzahl der Front-End-Ingenieure beginnt größer als 15 und das Unternehmen hat mindestens mehrere Frontend-Projekte.

Ich möchte nicht auf Managementprobleme oder Probleme mit Geschäftsdomänen eingehen, wie sie in so großen Unternehmen häufig auftreten, aber konzentrieren wir uns darauf stattdessen nur für die Frontend-Architektur.

Die Frontend-Architektur ist heutzutage in zu vielen Bereichen involviert. Daher würde ich zunächst vorschlagen, sie in die folgenden Abschnitte zu unterteilen:

Frontend-Architekturschema

1. Visueller Code

Beginnen wir mit dem einfachsten Thema, meiner Meinung nach ist es der visuelle Code unserer Anwendungen.

Höchstwahrscheinlich, weil wir mehrere Frontend-Anwendungen bei derselben Firma entwickeln, die wir möchten zu haben:

  • Markenbekanntheit
  • dieselbe UI / UX

Um dies zu erreichen, benötigen wir ein Design-System. Das Designteam muss das Designsystem entwickeln und diese Designrichtlinien bei allen zukünftigen Produktdesigns befolgen. Auch dies ist bereits eine sehr komplexe Aufgabe und erfordert viele Diskussionen und Anpassungen zwischen dem Designteam, den Ingenieuren und dem Produkt.

Vom Front-End-Standpunkt aus müssen wir ein Tool bereitstellen, das implementiert und umgesetzt werden kann Teilen Sie dieses Konstruktionssystem zwischen Ingenieuren. Eine gute Lösung hierfür kann die Erstellung des npm-Pakets sein, das visuell durch ein Storybook oder ein ähnliches Tool dargestellt wird. Meiner Meinung nach ist es sehr wichtig, eine dedizierte Webressource (mit URL) mit Dokumentation zur Verwendung dieses Pakets zu haben. Diese Webressource wird von Front-End-Ingenieuren und Designern verwendet und kann ein hervorragender Bezugspunkt sein Gespräche zwischen ihnen.

Visueller Code

Zusammenfassung:

Zu diesem Zeitpunkt haben wir ein Entwurfssystem und seine Darstellung in einem Paket und einer interaktiven Dokumentation dafür. Wir teilen und übernehmen dieses Paket für alle unsere Front-End-Anwendungen.

2. Codestruktur

Lassen Sie uns über a sprechen ein bisschen über das tägliche Engineering. Wir implementieren neue Funktionen, beheben Fehler und überarbeiten den Code bei Bedarf. Wir kümmern uns um unsere Codebasis und versuchen, sie schön und leicht verständlich zu machen. Aber was passiert, wenn wir nicht 1, nicht 2, sondern Dutzende kleiner oder großer Projekte im Unternehmen haben? Normalerweise werden Personen um einige der Projekte gruppiert und beginnen nur mit dieser Gruppe von Projekten zu arbeiten. Aufgrund unserer menschlichen Natur und der begrenzten Zeit können wir normalerweise nicht mehr als 2–3–5 Projekte gleichzeitig bearbeiten. Natürlich haben wir diese Gruppen von Einflüssen. Übrigens, danke an die NASA für ein so erstaunliches Foto für meine Analogie 😃

Gruppen von Einflüssen

Aber wir haben immer mehr Fälle, in denen Menschen sich kreuzen -Teams arbeiten zusammen, müssen den Code und die Lösungen des anderen überprüfen, einige Fehler auch in anderen Anwendungen beheben oder etwas hinzufügen, das sie in einer externen App benötigen (extern für ihre Einflussgruppe). Die schlechte Nachricht – dass dieser Prozess in großen Unternehmen fast unkontrolliert abläuft. Die gute Nachricht – wir können helfen, sie zu verbessern.

Wie? Richtig. Indem Sie dieselbe Codestruktur , Codierungs- und Strukturierungsrichtlinien für alle bereitstellen die Projekte im Unternehmen.

Lassen Sie uns näher auf das eingehen, was wir unter Codestruktur verstehen:

  • Die Ordnerstruktur im Projekt
    Wenn Ingenieure zum ersten Mal in ein neues Projekt springen – mit derselben Ordnerstruktur wie in ihrem Projekt, in dem sie wissen, dass alles beim Navigieren und Suchen sehr hilfreich ist.
  • Konfigurations- oder Unterstützungsdateien
    Dateien wie package.json, .gitignore, .editorconfig, webpack.config usw. Sie sollten sich in jedem Projekt immer am selben Ort befinden. Dasselbe wird bei Bedarf mit Testkonfigurationsdateien oder CI-Dateien verbunden.
  • Fester Speicherort der Dateitypen
    Wenn der Speicherort derselben Dateitypen folgt Immer die gleiche Struktur funktioniert es auch super. Wenn der Komponentenordner beispielsweise immer eine style.css -Datei enthält:
/Component
--/Component.tsx
--/style.css
--/index.ts
  • Interne Struktur der Komponenten
    Die Struktur in Dateien sollte dieselbe sein: Reihenfolge der Importe, Exporte, Position der öffentlichen Funktion , Typen usw. In jedem Dateityp sollten Sie wissen, was Sie erwartet.
  • Namenskonventionen
    Dies umfasst Namen der Ordner, Dateien, Variablen, Funktionen, Klassen, Typen usw.
  • Codierungskonventionen
    Im Allgemeinen würde ich sagen, dass Codierungskonventionen ein sehr breiter Abschnitt sind, aber hier möchte ich nur Dinge einschließen, die nicht in den Rest der Abschnitte passen, wie z. B. ; oder not ; 😁 und ähnlich .

Die gleiche Codestruktur und das Projekt-Toolset sind in der Praxis sehr eng miteinander verbunden äh und helfen sich gegenseitig beim Zusammenleben. Mit Toolset meine ich CLI-Tools (Projekt-Bootstrapping, Flusen, Testen usw.), IDE-Erweiterungen usw. Wir werden das Toolset-Thema in den nächsten Abschnitten diskutieren.

Codestruktur

Zusammenfassung:

Nachdem Sie diesen Abschnitt angewendet und übernommen haben, sollten alle Projekte im gesamten Unternehmen dieselbe Ordnerstruktur, Namensrichtlinien, Dateistruktur usw. haben. Jeder Entwickler kann idealerweise in jedes andere Projekt springen und dort nicht komplett verloren gehen. Dieses „vollständig verlorene“ Element hängt auch stark mit dem Technologie-Stack zusammen, der im Projekt verwendet wird. Sprechen wir also darüber.

3. Tech-Stack

Ähnlich wie beim vorherigen Abschnitt möchten wir einen einheitlichen Tech-Stack über die Projekte der Organisation hinweg haben. Die Gründe dafür sind sehr ähnlich – Wir möchten, dass unsere Ingenieure mit allen Projekten im gesamten Unternehmen vertraut sind.

In Frontend-Projekten können die Komponenten des Tech-Stacks sein: Framework, basierend auf dem erstellten Projekt, die Hauptsprache, Stilprozessor, Datenschicht (z. B. Apollo), Statusverwaltung, Tests, Code-Flusen, Build-System und andere.

Natürlich gibt es in allen Regeln Ausnahmen. Und in diesem Thema möchte ich auch machen Eine Bemerkung, dass einige Technologien manchmal sehr gut zu bestimmten Projekten passen, auch wenn diese Technologien nicht Teil des globalen unternehmensweiten Tech-Stacks sind Pany Tech Stack sollten Sie sich zweimal überlegen, da die Kosten für die Unterstützung solcher Dinge sehr hoch sind. Daher müssen die Vorteile dramatisch sein.

Lassen Sie uns hier einen generischen Tech Stack erwähnen, der jetzt für die meisten Projekte geeignet ist ( Natürlich deckt es nur einen Teil des realen Tech-Stacks ab, kann aber ein guter Ausgangspunkt für jemanden sein 🤷):

Stack

Nachdem wir den Tech-Stack in unserem Unternehmen definiert und vereinbart haben, gibt es auch andere sehr wichtige Erfolgssäulen .

Zuerst müssen wir notieren Sie den Tech-Stack im Dokument . Das Dokument , das zwischen Ingenieuren gut und einfach geteilt werden sollte , damit sie als Beweis immer einen Link zueinander geben können.

Zweitens – wir sollten das -Dokument mit der Art und Weise , wie die neuen Projekte gestartet und mithilfe des definierten Tech-Stacks gebootet werden sollen

Tech Stack

Zusammenfassung:

Nachdem wir alles implementiert und übernommen haben, was wir oben erwähnt haben, sollten Sie dies tun Lassen Sie alle Ihre Projekte in der Organisation denselben Tech-Stack gemeinsam nutzen. Idealerweise ohne Unterschiede. Nicht ideal – mit unbedeutenden Unterschieden. Wenn wir auch den vorherigen Abschnitt hinzufügen, sollten Code, Ordner und Dateistruktur ebenfalls fast gleich sein identisch in Ihren Projekten.Das Navigieren durch ein Projekt sollte daher eine sehr einfache Aufgabe sein. Gut 😊

4. Werkzeug

Dieses Thema ist sehr wichtig. Wir verwenden jetzt fast überall einige zusätzliche Tools – zum Flusen, Erstellen unserer Apps, CI, Komponentengeneratoren und vielem mehr. Deshalb sehe ich, ob wir das richtige Werkzeug für unsere Projekte auswählen können – es ist entscheidend. Gutes Werkzeug gegen schlechtes Werkzeug (oder überhaupt kein Werkzeug), es ist Das gleiche wie ein Vergleich zwischen Automatisierung und manuellem Testen .

Wir haben gerade in den vorherigen Abschnitten über Tech-Stack und Codestruktur gesprochen und erwähnt, dass wir schreiben müssen eine Menge Dokumentation, damit die Leute ihnen folgen. Das richtige Toolset bietet Ihnen jedoch die Möglichkeit, gemäß den Richtlinien in Ihrem Unternehmen zu automatisieren. .

Für Wenn Sie beispielsweise einen bestimmten Codierungsstil haben, können Sie den Benutzern das Flusen-Toolset geben, das standardmäßig diesen Regeln folgt. Wenn Sie über den definierten Tech-Stack verfügen, können Sie mit einem guten CLI-Tool ein neues Projekt mit diesen spezifischen Technologien von Ihrem Tech-Stack booten.

Versuchen wir zu diskutieren, welche Teile von Ihre Frontend-Architektur kann durch folgende Tools abgedeckt werden:

  • Codestil und -struktur
    Wie bereits erwähnt, kann dies einfach mit Tools automatisiert werden.
  • Projekt-Bootstrapping
    Sie tun es nicht. “ Es muss keine neue Projektstruktur erstellt werden, bei der alle benötigten Pakete usw. manuell installiert werden.
  • Komponentengenerierung
    Meistens enthält eine Komponente in Ihrer Anwendung nicht einmal eine einzelne Datei, daher kann das Erstellen, Verknüpfen / Importieren von Dateien einige Zeit in Anspruch nehmen, sodass dies automatisiert werden kann.
  • Starten und Erstellen
    Natürlich das offensichtlichste für Auto mate – wie Sie Ihre Anwendung erstellen oder starten.
  • Tests
    Der Prozess zum Erstellen Ihrer Anwendung App für Tests und tatsächliche Ausführung aller Arten von Tests – Einheit, Integration usw.
  • Abhängigkeitsverwaltung
    Wie wir wissen, sind derzeit rund 80\% unseres Codes Abhängigkeiten. Wir müssen sie also auf dem neuesten Stand halten und es ist nicht einfach, dies in einem großen Unternehmen zu verwalten.
  • Projektübergreifende Abhängigkeiten
    Höchstwahrscheinlich arbeiten unsere Projekte nicht isoliert und hängen möglicherweise von anderen Projekten ab oder sind eine Abhängigkeit für ein anderes Projekt. Daher benötigen wir möglicherweise einige Tools, um den Verknüpfungsprozess zu vereinfachen. Entwickeln in einer Kombination mehrerer Projekte (wie z. B. Bit ) usw.
  • CI
    CI ist ein wesentlicher Bestandteil unseres täglichen Toolset, und die Automatisierung und Vereinheitlichung kann für Ihr Unternehmen eine sehr nützliche Arbeit sein.

Wenn Sie kein neues eigenes Toolset entwickeln möchten, kann ich das NX-Toolset als einen der interessantesten Kandidaten empfehlen Es sieht so aus, als würden die Entwickler von Babel eine ähnliche Lösung finden, die Sie vielleicht ausprobieren möchten – Rom . Diese Tools decken nicht alles ab, sondern einen großen Teil dessen, worüber wir gesprochen haben. Sie können daher ein guter Ausgangspunkt sein.

Tooling

Zusammenfassung:

Stellen Sie sich vor, wie großartig unsere Architektur werden kann, nachdem wir alle Abschnitte erstellt und übernommen haben.

Jedes Projekt ist das gleiche und wird vom einheitlichen Toolset verwaltet und verwaltet. Jedes Projekt kann auf dieselbe Weise gestartet und erstellt werden. Neue Komponenten werden am selben Ort und mit denselben Namensrichtlinien generiert.

Aber ist es so „süß“ oder hat es Nachteile? Wie bei jeder Lösung hat es Nachteile. Eine davon – es braucht einige Zeit, um neue Ingenieure in Ihr Unternehmen aufzunehmen. Wenn jedoch alles auf sehr natürliche Weise erledigt wird (wie es die Leute bereits in anderen vorhandenen Tools gewohnt waren) und dokumentiert wird, wird dies kein großes Problem, wenn man es mit den Vorteilen der Entwicklungsgeschwindigkeit vergleicht, eine Gelegenheit für Ingenieure, mit der sie arbeiten können jede Codebasis leicht usw.

5. Produktion

Über diesen Teil der Frontend-Architektur kümmern sich Ingenieure normalerweise am wenigsten.Vielleicht, weil es die meiste Zeit nicht mit der Codierung selbst zusammenhängt – und wahrscheinlich nicht so aufregend, aber nicht zuletzt wichtig –

In der Produktion müssen wir uns normalerweise um die nächsten Dinge kümmern:

  • Analytics
    Alle Arten von verschiedenen Tracking-Ereignissen usw. Dinge wie Google Analytics , Segment , HotJar usw.
  • Statusüberwachung
    Dies schließt Dinge wie Gesundheitsprüfungen ein Sogar Tests werden für die Produktion, Fehlerberichte (wie Sentry ) usw. ausgeführt.
  • Leistung
    Dies ähnelt dem vorherigen Element, ist jedoch stärker auf die Leistung ausgerichtet. Dazu gehört das Messen der Reaktionszeit, der ersten aussagekräftigen Farbe usw. (wahrscheinlich Werkzeug Nr. 1 – Leuchtturm )
  • A / B-Tests
    Alle Arten von A / B-Testlösungen oder Feature-Flags.
  • Caching
    Tools wie Lack , Cloudflare .

Alle können in Ihren Front-End-Anwendungen im Unternehmen vereinheitlicht werden, was das Leben Ihrer Ingenieure vereinfacht . Beispiel: Fügen Sie Pakete mit den vordefinierten Anfangskonfigurationen hinzu und fügen Sie diese Pakete Ihrem Bootstrapping-Projekt hinzu.

Ein weiterer Teil der Produktion ist die Codevorbereitung, z. B.:

  • Minimierung
    Nur Code-Minimierung 😄
  • Quellzuordnung
    Quellzuordnungen werden möglicherweise auch für einige andere Tools wie Sentry benötigt.
  • Vorbereitung von Assets
    Vorbereitung für Bildschirme mit unterschiedlichen Auflösungen, Zuschneiden von Bildern usw.

Dies sind großartige Kandidaten, die hinzugefügt werden sollten Das Toolset für die Verwaltung von Front-End-Anwendungen, über das wir im Abschnitt „Tools“ gesprochen haben.

Produktion

Zusammenfassung:

Idealerweise sollten alle diese sein Wird in der Bootstrapping-Phase standardmäßig zu jedem Frontend-Projekt hinzugefügt. Und Ingenieure würden sich nur darum kümmern, korrekte API-Schlüssel an den richtigen Stellen für die Tools hinzuzufügen.

6. Entwicklung

CLI-Tool

Teilweise haben wir die Entwicklungserfahrung bereits im Abschnitt Tooling besprochen, als wir das Frontend-CLI-Tool berührten. Unified Tooling ist ein großer Teil der täglichen Arbeit der Ingenieure, aber nicht alles.

API

Eine komfortable API für die lokale Arbeit ist die zweite großartige Möglichkeit, den Entwickler zu verbessern Erfahrung und Entwicklungsgeschwindigkeit. Normalerweise ist das lokale Bereitstellen von APIs für Front-End-Ingenieure kein trivialer Prozess: Dies kann die Installation von Tools oder Frameworks umfassen, mit denen sie nicht vertraut sind. Selbst wenn das Setup dockerisiert ist, kann dies einen enormen Rechenaufwand erfordern Ressourcen von den Computern des Entwicklers (falls nicht – dies kann als Setup betrachtet werden). Was kann in diesem Fall eine Lösung sein – extern bereitgestellte API. Dies kann ein einzelner Server für alle Ingenieure oder ein Mechanismus zum Booten sein leicht Ihr eigener dedizierter Server für die Entwicklung.

CI

CI ist der dritte große Teil. Ich könnte annehmen, dass Ihr Unternehmen bereits ein CI-Tool für das Frontend ausgewählt und dieses einzelne Tool verwendet hat (z. B. Kreis CI ,

Concourse CI oder eine andere). Wenn nicht, sollten Sie dies vereinheitlichen.

Die CI-Konfiguration des jeweiligen Projekts sollte meiner Meinung nach Teil der Aufgabe des Teams sein, das an dem Projekt arbeitet. Dies gibt CI die Chance, stabil zu sein, da es Leute gibt, die daran interessiert sind, dass CI arbeitet, es jeden Tag verwendet und über die Fähigkeit und die Fähigkeiten verfügt, es zu reparieren, zu konfigurieren und zu verbessern.

Nicht alle Arbeiten sollten vom Team ausgeführt werden. Für Front-End-Anwendungen gibt es eine ziemlich spezifische Reihe von Jobs, die möglicherweise benötigt werden können. Insbesondere, wenn es uns gelingt, die Ordner- / Codestruktur, den Tech-Stack usw. zu vereinheitlichen. Nach einiger Zeit in Ihrem Unternehmen kann es daher vorkommen, dass Sie diese Muster für Phasen Ihres CI-Tools erkennen und diese Phasen als implementieren können eine Art „Bausteine“ und geben Sie Ihren Ingenieuren die Möglichkeit, ihre CI-Pipelines einfach aus diesen einheitlichen „Bausteinen“ zu konstruieren.

Demo-Umgebungen

Und schließlich die letzte Überprüfung von die implementierte Funktion.Nachdem die Ingenieure alles erledigt und implementiert haben, müssen sie fast immer irgendwie überprüfen, wie es aussieht und wie es funktioniert, und dies mit anderen Ingenieuren, Designern oder anderen Interessengruppen teilen. Für solche Anforderungen funktioniert die temporär bereitgestellte Version Ihrer Anwendung für den spezifischen PR mit der angegebenen URL sehr gut.

App vorübergehend bereitgestellt
App vorübergehend bereitgestellt

Diese Lösung beschleunigt die Kommunikation zwischen verschiedenen Teams und Personen erheblich, und ich denke, dies ist nur eine haben müssen. Diese vorübergehend bereitgestellte Version sollte jedoch so produktionsnah wie möglich sein, da sie auch ein hervorragendes Tool zum Überprüfen einiger Oberflächenfehler oder Fehler sein kann.

Dies kann problemlos zu Ihren Projekten hinzugefügt und in Ihrem Frontend automatisiert werden Pipelines zum Erstellen und Bereitstellen von Anwendungen werden vereinheitlicht. Auch solche oder ähnliche Tools wie Kubernetes und Helm können bei der Implementierung sehr hilfreich sein.

Entwicklung

Zusammenfassung:

Komfortable und effiziente Entwicklungsabläufe mit einem einzigen CI-Tool mit Bausteinen CI-Pipeline mit einheitlichen CLI-Frontend-Tools und den Demo-Umgebungen. All dies sollte unseren Entwicklungsprozess so reibungslos wie möglich gestalten. Multiplizieren Sie dies mit der Anzahl der Ingenieure, die Sie im Unternehmen haben, und Sie werden verstehen, wie vorteilhaft es ist.

7. Modularität

Dieses Thema ist sehr umfangreich und erfordert möglicherweise einen separaten Artikel, aber ich würde versuchen, es kurz durchzugehen.

In großen Organisationen sind große Codebasen keine Seltenheit Sache. Bei all den bekannten Problemen, die damit einhergehen, wie langsamen CI-Pipelines, Problemen bei der Zusammenarbeit, langsamen Tests usw. Das große Stück der Frontend-Architektur ist also die Entscheidung darüber, wie detailliert unabhängige Frontend-Anwendungen / -Module angezeigt werden sollen.

Es gibt drei Hauptmodelle, die wir jetzt haben:

  • Monolith
    Ein großes Repository mit einem einzigen Projekt und dem gesamten Code. Alle Teams arbeiten gleichzeitig an diesem Repository.
  • Monorepo
    Viele Projekte, aber immer noch ein großes Repository ( monorepo im Wiki ). Alle Teams arbeiten immer noch am selben Repository, jedoch mit unterschiedlichen Projekten. Es gibt bereits Möglichkeiten, einige Probleme zu beheben, die wir mit einem Monolith-Ansatz haben, indem Pipelines nur für bestimmte Projekte ausgeführt werden, Projekte mit kleineren Testsuiten usw. Tools wie Lerna kann Ihnen das Leben erheblich erleichtern, wenn Sie diesen Ansatz wählen.
  • Repo pro Projekt
    Jedes Projekt verfügt über ein eigenes Repository und alle unterstützenden Dinge wie CI-Pipelines, Bereitstellungen usw.

In all diesen Modellen kann das Projekt eine unabhängige Frontend-Anwendung, Seite, bedeuten. unabhängiges Frontend-Modul usw. Dies hängt davon ab, wie detailliert Sie Ihre Front-End-Anwendungen aufteilen möchten. In den meisten Fällen sollte diese Aufteilung mit der gewünschten Organisationsstruktur und Personalverwaltung synchronisiert sein.

Das zweite große Thema nach der Entscheidung, wie Ihre Anwendung aufgeteilt werden soll, ist die Verbindung dieser Teile (falls Sie sich entschieden haben) um Ihre Anwendung zu teilen).

Und hier haben wir die nächsten Ansätze:

  • Erstellung während der Erstellung
    Ihre Projekte können nur npm-Pakete sein, die während der Erstellungszeit installiert und zusammengestellt werden.
  • Server- Seitenzusammensetzung
    Dieser Ansatz umfasst normalerweise das Rendern auf der Serverseite und die Komposition auf einem Server. Solche Tools wie Hypernova können helfen, sie besser zu organisieren.
  • Clientseitige Komposition
    Zusammensetzung der Projekte im Browser. In Martin Fowlers Blog gibt es eine ziemlich gute Erklärung für einige Ansätze – hier . Auch sehr wichtig, Module Federation , ein neuer Ansatz, der in Webpack 5 eingeführt wurde.
  • Routenkomposition
    Super einfach – nur jedes Projekt hat eine eigene URL und auf „Nginx-Ebene“ entscheiden wir, wohin Benutzer umgeleitet werden sollen.(Entschuldigung, für eine solche Erklärung 😄, aber ich dachte, dies ist am einfachsten zu verstehen)

Wie ich bereits sagte, ist es sehr schwierig, dieses Thema in einem so kleinen Format zu behandeln. aber ich hoffe, Sie haben zumindest einige interessante Ideen für sich gefunden und werden sich selbst mit den Themen befassen 🙏🏻 .

Modularität

Zusammenfassung:

Wir haben einen Weg gefunden, unsere Teams glücklich und produktiv zu machen, indem wir die Repositories organisiert und unsere Projekte (höchstwahrscheinlich) in kleinere Teile aufgeteilt haben. indem Sie Teams unabhängiger voneinander machen.

Willkommen im Paradies 😁

8. Testen

Es gibt so viele Ressourcen zum Testen von Front-End-Anwendungen, dass ich versuchen würde, nicht auf Details einzugehen, die Sie können easi Finden Sie, aber konzentrieren Sie sich mehr auf die Probleme großer Unternehmen und wie wir sie lösen können.

Der erste von ihnen – jeder Ingenieur versteht die Testtechniken anders, auch welche Technik in welcher Situation anzuwenden ist, wie man schreibt “ Gute Tests usw. Daher ist es sehr sinnvoll, alle Nuancen und Richtlinien der im Unternehmen verwendeten Teststufen und die Richtlinien für jede dieser Tests ziemlich genau zu dokumentieren.

Mögliche Teststufen, die Sie möchten haben in Ihrer Teststrategie:

  • Unit-Test
  • Integrationstest
  • E2E-Test
  • … und andere

Als zweiten Schritt müssen wir sie außerdem über verschiedene Frontend-Anwendungen im Unternehmen hinweg vereinheitlichen, damit die Mitarbeiter keine Fragen dazu haben, wie und was zu testen ist, wenn sie in ein anderes Projekt verschoben werden.

Wenn Sie es geschafft haben, die Teststufen und -ansätze zu vereinheitlichen, können Sie automatisch zur Lösung des zweiten Problems beitragen – der Einrichtung der Testinfrastruktur. Jedes Projekt für sich muss es lokal und auf CI einer Testinfrastruktur einrichten und konfigurieren. Zum Beispiel haben wir beschlossen, Cypress zu verwenden, und es muss in einem Docker-Image ausgeführt werden. Dies muss einige Zeit dauern, um lokal und auf CI eingerichtet zu werden. Wenn wir das mit der Anzahl der Projekte multiplizieren, die wir haben, ist dies eine enorme Menge an Zeit. Die Lösung besteht also darin, dies erneut zu vereinheitlichen und einige Werkzeuge für die Projekte bereitzustellen. Klingt einfach, erfordert jedoch viel Zeit für die Implementierung.

Testen ohne Entwicklungszeit

Ich wollte auch eine andere Möglichkeit zum Testen Ihrer Anwendungen ansprechen, nachdem Funktionen bereits implementiert und bereitgestellt wurden. Und ja, natürlich ist die Überwachung Teil davon 😁.

Wir haben bereits in den vorherigen Abschnitten die Fehler- und Leistungsüberwachung für Frontend-Anwendungen, die Überwachung der Betriebszeit und die Reaktion von verschiedenen Standorten aus erwähnt.

Es ist auch großartig, Lighthouse -Tests werden auf Ihrer Website ausgeführt (können in die CI-Pipelines aufgenommen werden), um einfachere Leistungsengpässe und Probleme mit der Barrierefreiheit zu ermitteln und die Qualität von Webseiten im Allgemeinen zu verbessern.

Und die last – Produktionstests für die wichtigsten Geschäftsabläufe. Höchstwahrscheinlich funktionieren sie am besten, wenn Sie sie direkt auf dem Produkt ausführen in der Umgebung, kann aber auch eine Änderung möglich sein, wenn wir solche Tests in einer Staging- / Testumgebung ausführen können, die der Produktionsumgebung sehr nahe kommt oder diese sogar spiegelt. Zu diesem Thema gibt es einen sehr schönen Artikel – (hier).

Testen

Zusammenfassung:

Wir haben Klare Testrichtlinien mit definierten erforderlichen Teststufen für jede Frontend-Anwendung. Wir haben eine einzige CI-Pipeline für jede Anwendung und ein einziges CLI-Tool, mit dem Tests lokal ausgeführt werden können.

Letztes Wort

Ich hoffe wirklich, dass Sie daran etwas Interessantes gefunden haben Artikel. Es tut mir sehr leid, dass ich in den meisten Themen nur die Oberfläche der Probleme zerkratzt habe. Und wir werden sie gerne weiter diskutieren. Bitte hinterlassen Sie Ihre Fragen in den Kommentaren oder pingen Sie mich direkt auf Twitter an – @denieler .