Testen von Node.js-Projekten. Teil 2. Bewertung der Testleistung, kontinuierliche Integration und Analyse der Codequalität

→ Testen von Node.js-Projekten. Teil 1. Testanatomie und Testtypen

Im zweiten Teil der Übersetzung von Material zum Testen von Node.js-Projekten werden wir heute über die Bewertung der Wirksamkeit von Tests und die Analyse der Qualität des Codes sprechen.

Abschnitt 3. Bewertung der Wirksamkeit von Tests

▍19. Erreichen Sie mit Tests eine ausreichend hohe Codeabdeckung, um Vertrauen in den korrekten Betrieb zu gewinnen. Normalerweise liefert eine Abdeckung von ungefähr 80% gute Ergebnisse.

Empfehlungen

Der Zweck des Testens besteht darin, sicherzustellen, dass der Programmierer weiterhin produktiv an dem Projekt arbeiten kann, um sicherzustellen, dass das, was bereits getan wurde, korrekt ist. Je größer das Volumen des getesteten Codes ist, desto stärker ist natürlich das Vertrauen, dass alles so funktioniert, wie es sollte. Der Indikator für die Codeabdeckung durch Tests gibt an, wie viele Zeilen (Zweige, Befehle) durch Tests überprüft wurden. Was soll dieser Indikator sein? Es ist klar, dass 10-30% zu wenig sind, um sicher zu sein, dass das Projekt fehlerfrei funktioniert. Andererseits kann sich der Wunsch nach einer 100% igen Abdeckung des Codes mit Tests als zu teuer herausstellen und den Entwickler von den wichtigsten Programmfragmenten ablenken, sodass er im Code nach Stellen suchen muss, die die vorhandenen Tests nicht erreichen. Wenn Sie eine umfassendere Antwort auf die Frage geben, wie der Code mit Tests abgedeckt werden soll, können wir sagen, dass der Indikator, nach dem wir streben sollten, von der zu entwickelnden Anwendung abhängt. Wenn Sie beispielsweise Software für den Airbus A380 der nächsten Generation schreiben, ist 100% ein Indikator, der nicht einmal diskutiert wird. Wenn Sie jedoch eine Website erstellen, auf der Karikaturgalerien angezeigt werden, sind wahrscheinlich 50% bereits viel. Obwohl Testexperten sagen, dass der Grad der Codeabdeckung mit Tests, die Sie anstreben sollten, vom Projekt abhängt, erwähnen viele von ihnen die 80% -Zahl, die wahrscheinlich für die meisten Anwendungen geeignet ist. Zum Beispiel sprechen wir hier von etwas im Bereich von 80-90%, und laut dem Autor dieses Materials macht ihn eine 100% ige Abdeckung des Codes mit Tests misstrauisch, da dies darauf hindeuten kann, dass der Programmierer Tests nur schreibt, um sie zu erhalten schöne Nummer im Bericht.

Um die Indikatoren für Codeabdeckungstests verwenden zu können, müssen Sie Ihr System für die kontinuierliche Integration (CI, Continuous Integration) ordnungsgemäß konfigurieren. Auf diese Weise kann die Montage des Projekts gestoppt werden, wenn der entsprechende Indikator einen bestimmten Schwellenwert nicht erreicht. Hier erfahren Sie, wie Sie Jest so konfigurieren, dass Informationen zur Testabdeckung erfasst werden. Darüber hinaus können Sie Abdeckungsschwellenwerte nicht für den gesamten Code konfigurieren, sondern sich auf einzelne Komponenten konzentrieren. Erwägen Sie außerdem, eine Abnahme der Testabdeckung festzustellen. Dies geschieht beispielsweise, wenn Sie einem Projekt neuen Code hinzufügen. Die Steuerung dieses Indikators ermutigt Entwickler, das Volumen des getesteten Codes zu erhöhen oder zumindest dieses Volumen auf dem vorhandenen Niveau zu halten. In Anbetracht des oben Gesagten ist die Abdeckung von Code mit Tests nur ein quantifizierter Indikator, der nicht ausreicht, um die Zuverlässigkeit von Tests vollständig zu bewerten. Wie weiter unten gezeigt wird, bedeuten die hohen Werte noch nicht, dass der Code „mit Tests abgedeckt“ wirklich überprüft wird.

Folgen der Abweichung von den Empfehlungen

Das Vertrauen des Programmierers in die hohe Qualität des Codes und die damit verbundenen Indikatoren im Zusammenhang mit dem Testen gehen Hand in Hand. Ein Programmierer kann nicht anders, als Angst vor Fehlern zu haben, wenn er nicht weiß, dass der größte Teil des Codes für sein Projekt durch Tests abgedeckt ist. Diese Bedenken können Ihr Projekt verlangsamen.

Beispiel

So sieht ein typischer Testbericht aus.


Von Istanbul erstellter Testbericht

Richtiger Ansatz

Hier ist ein Beispiel für die Einstellung der gewünschten Testabdeckung des Komponentencodes und der allgemeinen Ebene dieses Indikators in Jest.


Festlegen der gewünschten Codeabdeckung mit Tests für das gesamte Projekt und für eine bestimmte Komponente

▍20. Untersuchen Sie Berichte zur Codeabdeckung mit Tests, um ungeschützte Teile des Codes und andere Anomalien zu identifizieren

Empfehlungen

Einige Probleme neigen dazu, durch eine Vielzahl von Fehlererkennungssystemen zu rutschen. Solche Dinge können mit herkömmlichen Werkzeugen schwer zu erkennen sein. Möglicherweise trifft dies nicht auf echte Fehler zu. Es handelt sich vielmehr um unerwartetes Anwendungsverhalten, das verheerende Folgen haben kann. Beispielsweise kommt es häufig vor, dass einige Codefragmente entweder nie verwendet oder selten aufgerufen werden. Sie denken beispielsweise, dass die Mechanismen der PricingCalculator Klasse immer zum PricingCalculator des Preises eines Produkts verwendet werden. Tatsächlich stellt sich jedoch heraus, dass diese Klasse überhaupt nicht verwendet wird und dass in der Datenbank und im Online-Shop, in dem das System verwendet wird, Aufzeichnungen von 10.000 Produkten vorhanden sind. Viele Verkäufe ... Berichte über die Codeabdeckung mit Tests helfen dem Entwickler zu verstehen, ob die Anwendung so funktioniert, wie sie funktionieren sollte. Darüber hinaus können Sie anhand der Berichte herausfinden, welcher Projektcode nicht getestet wurde. Wenn Sie sich auf einen allgemeinen Indikator konzentrieren, der angibt, dass Tests 80% des Codes abdecken, können Sie nicht herausfinden, ob kritische Teile der Anwendung getestet werden. Um einen solchen Bericht zu erstellen, reicht es aus, das Tool, mit dem Sie die Tests ausführen, ordnungsgemäß zu konfigurieren. Solche Berichte sehen normalerweise ziemlich hübsch aus, und ihre Analyse, die nicht viel Zeit in Anspruch nimmt, ermöglicht es Ihnen, alle möglichen Überraschungen zu erkennen.

Folgen der Abweichung von den Empfehlungen

Wenn Sie nicht wissen, welche Teile Ihres Codes noch nicht getestet wurden, wissen Sie nicht, wo Sie Probleme erwarten können.

Falscher Ansatz

Schauen Sie sich den nächsten Bericht an und überlegen Sie, was darin ungewöhnlich aussieht.


Bericht über ungewöhnliches Systemverhalten

Der Bericht basiert auf einem realen Anwendungsnutzungsszenario und ermöglicht es Ihnen, ungewöhnliches Programmverhalten zu sehen, das mit Benutzern verbunden ist, die sich am System anmelden. Eine unerwartet große Anzahl erfolgloser Versuche, in das System einzudringen, fällt nämlich im Vergleich zu erfolgreichen auf. Nach der Analyse des Projekts stellte sich heraus, dass der Grund dafür ein Fehler im Frontend war, aufgrund dessen der Schnittstellenteil des Projekts ständig entsprechende Anforderungen an die Server-API zur Eingabe des Systems sendete.

▍21. Messen Sie die logische Codeabdeckung mit Tests mithilfe von Mutationstests

Empfehlungen

Herkömmliche Benchmarking-Metriken sind möglicherweise unzuverlässig. Der Bericht kann also eine Zahl von 100% enthalten, aber gleichzeitig geben absolut alle Funktionen des Projekts falsche Werte zurück. Wie kann man das erklären? Tatsache ist, dass der Indikator für die Codeabdeckung durch Tests nur angibt, welche Codezeilen unter der Kontrolle des Testsystems ausgeführt wurden, aber nicht davon abhängt, ob etwas wirklich verifiziert wurde, dh ob die Aussagen des Tests waren zielte darauf ab, die Richtigkeit der Ergebnisse des Codes zu überprüfen. Dies ähnelt einer Person, die nach einer Geschäftsreise ins Ausland Briefmarken in ihrem Pass zeigt. Briefmarken beweisen, dass er irgendwohin gegangen ist, aber sie sagen nichts darüber aus, ob er das getan hat, was er auf Geschäftsreise gemacht hat.

Hier können uns Mutationstests helfen, mit denen wir herausfinden können, wie viel Code tatsächlich getestet und nicht nur vom Testsystem besucht wurde. Für Mutationstests können Sie die Stryker JS-Bibliothek verwenden. Hier sind die Prinzipien, nach denen es funktioniert:

1. Sie ändert den Code absichtlich und erzeugt Fehler darin. Beispielsweise wird der Code newOrder.price===0 zu newOrder.price!=0 . Diese "Fehler" nennt man Mutationen.
2. Sie führt Tests durch. Wenn sich herausstellt, dass sie bestanden wurden, haben wir Probleme, weil die Tests ihre Aufgabe, Fehler zu erkennen, nicht erfüllen und die „Mutanten“, wie sie sagen, „überleben“. Wenn die Tests Fehler im Code anzeigen, ist alles in Ordnung - die "Mutanten" "sterben".

Wenn sich herausstellt, dass alle "Mutanten" "getötet" wurden (oder zumindest die meisten von ihnen nicht überlebten), gibt dies ein höheres Maß an Vertrauen in die hohe Qualität des Codes und die Tests, die ihn testen, als herkömmliche Metriken zum Abdecken des Codes mit Tests. Gleichzeitig ist die Zeit, die zum Konfigurieren und Durchführen von Mutationstests erforderlich ist, mit der Zeit vergleichbar, die bei Verwendung herkömmlicher Tests benötigt wird.

Folgen der Abweichung von den Empfehlungen

Wenn der traditionelle Indikator für die Codeabdeckung durch Tests anzeigt, dass 85% des Codes durch Tests abgedeckt sind, bedeutet dies nicht, dass die Tests Fehler in diesem Code erkennen können.

Falscher Ansatz

Hier ist ein Beispiel für eine 100% ige Abdeckung des Codes mit Tests, bei denen der Code nicht vollständig getestet wird.

 function addNewOrder(newOrder) {   logger.log(`Adding new order ${newOrder}`);   DB.save(newOrder);   Mailer.sendMail(newOrder.assignee, `A new order was places ${newOrder}`);   return {approved: true}; } it("Test addNewOrder, don't use such test names", () => {   addNewOrder({asignee: "John@mailer.com",price: 120}); });//    100%, ,   ,     

Richtiger Ansatz

Hier ist der Mutationstestbericht, der von der Stryker-Bibliothek erstellt wurde. Hier können Sie herausfinden, wie viel Code nicht getestet wurde (dies wird durch die Anzahl der "überlebenden" "Mutanten" angezeigt).


Stryker-Bericht

Die Ergebnisse dieses Berichts lassen mit mehr Sicherheit als übliche Indikatoren für die Codeabdeckung bei Tests zu, dass die Tests wie erwartet funktionieren.

• Eine Mutation ist ein Code, der von der Stryker-Bibliothek absichtlich geändert wurde, um die Wirksamkeit eines Tests zu testen.
• Die Anzahl der "getöteten" "Mutanten" (getötet) zeigt die Anzahl der absichtlich erzeugten Codedefekte ("Mutanten"), die während des Tests identifiziert wurden.
• Die Anzahl der "überlebenden" "Mutanten" (überlebt) ermöglicht es Ihnen herauszufinden, wie viele Codefehler-Tests nicht gefunden wurden.

Abschnitt 4. Kontinuierliche Integration, andere Codequalitätsindikatoren

▍ 22. Nutzen Sie die Funktionen von linter und unterbrechen Sie den Erstellungsprozess des Projekts, wenn Probleme erkannt werden, die gemeldet werden

Empfehlungen

Linters sind heute leistungsstarke Tools, mit denen schwerwiegende Codeprobleme erkannt werden können. Es wird empfohlen, zusätzlich zu einigen grundlegenden Flusenregeln (wie den durch die Plugins eslint-plugin-standard und eslint-config-airbnb implementierten ) spezielle Regeln zu verwenden. Dies sind beispielsweise die Regeln, die mithilfe des eslint-plugin-chai-expected-Plugins implementiert wurden, um die Richtigkeit des Testcodes zu überprüfen. Dies sind die Regeln des eslint-plugin-versprechen-Plugins , die die Arbeit mit Versprechungen steuern. Dies sind die Regeln der eslint-plugin-Sicherheit , die den Code auf Verfügbarkeit prüfen es enthält gefährliche reguläre Ausdrücke. Hier können Sie auch das Plugin eslint-plugin-you-dont-need-lodash-underscore erwähnen , mit dem Sie im Code die Verwendung von Methoden aus externen Bibliotheken finden können, die Analoga in reinem JavaScript enthalten.

Folgen der Abweichung von den Empfehlungen

Es ist ein regnerischer Tag gekommen, das Projekt führt zu kontinuierlichen Produktionsfehlern und es gibt keine Informationen zu Fehlerstapeln in den Protokollen. Was ist passiert? Wie sich herausstellte, ist das, was der Code als Ausnahme auslöst, nicht wirklich ein Fehlerobjekt. Infolgedessen werden Informationen über den Stapel nicht in die Protokolle aufgenommen. Tatsächlich kann der Programmierer in einer solchen Situation entweder gegen die Wand töten oder, viel besser, 5 Minuten damit verbringen, den Linter einzurichten, wodurch das Problem leicht erkannt und das Projekt vor ähnlichen Problemen geschützt wird, die in Zukunft auftreten können.

Falscher Ansatz

Hier ist der Code, der versehentlich ein gewöhnliches Objekt als Ausnahme auslöst, während Sie hier ein Objekt vom Typ Error benötigen. Andernfalls werden die Daten zum Stapel nicht in das Protokoll aufgenommen. ESLint findet heraus, was Produktionsprobleme verursachen kann, und hilft, diese Probleme zu vermeiden.


ESLint hilft Ihnen, einen Fehler in Ihrem Code zu finden

▍23. Schnelleres Feedback mit Entwicklern, die die lokale kontinuierliche Integration verwenden

Empfehlungen

Verwenden Sie ein zentrales System der kontinuierlichen Integration, mit dessen Hilfe Sie die Qualität des Codes kontrollieren, testen, den Linter verwenden und auf Schwachstellen prüfen können? Stellen Sie in diesem Fall sicher, dass Entwickler dieses System lokal ausführen können. Auf diese Weise können sie ihren Code sofort überprüfen, was das Feedback beschleunigt und die Projektentwicklungszeit verkürzt. Warum ist das so? Ein effektiver Entwicklungs- und Testprozess umfasst viele zyklisch wiederholte Vorgänge. Der Code wird getestet, der Entwickler erhält einen Bericht, und bei Bedarf wird der Code überarbeitet. Danach wird alles wiederholt. Je schneller die Rückkopplungsschleife funktioniert, desto schneller erhalten die Entwickler Berichte über Codetests, desto mehr Iterationen zur Verbesserung dieses Codes können sie durchführen. Wenn das Abrufen eines Testberichts viel Zeit in Anspruch nimmt, kann dies zu einer schlechten Codequalität führen. Angenommen, jemand hat an einem Modul gearbeitet, dann mit der Arbeit an einem anderen Modul begonnen und dann einen Bericht über das Modul erhalten, der angibt, dass das Modul verbessert werden muss. Da sich der Entwickler jedoch bereits mit völlig anderen Themen beschäftigt, wird er dem Problemmodul nicht genügend Aufmerksamkeit schenken.

Bei einigen CI-Lösungsanbietern (dies gilt beispielsweise für CircleCI ) können Sie die CI-Pipeline lokal ausführen. Einige kostenpflichtige Tools wie Wallaby.js (der Autor stellt fest, dass er nicht mit diesem Projekt verbunden ist) können schnell wertvolle Informationen über die Qualität des Codes erhalten. Darüber hinaus kann der Entwickler einfach das entsprechende npm-Skript zu package.json , das Codequalitätsprüfungen durchführt (Tests, Analysen mit einem Linter, Suche nach Schwachstellen) und sogar das gleichzeitige Paket verwendet, um die Überprüfungen zu beschleunigen. Um den Code jetzt umfassend zu überprüfen, reicht es aus, einen einzelnen Befehl wie die npm run quality und sofort einen Bericht zu erhalten. Wenn die Codetests ergeben, dass Probleme vorliegen, können Sie Commits mithilfe von Git-Hooks abbrechen (die Husky- Bibliothek kann zur Lösung dieses Problems hilfreich sein).

Folgen der Abweichung von den Empfehlungen

Wenn ein Entwickler einen Tag nach dem Schreiben dieses Codes einen Bericht über die Qualität des Codes erhält, wird ein solcher Bericht wahrscheinlich zu einem formalen Dokument, und Codetests werden von der Arbeit getrennt und nicht zu ihrem natürlichen Bestandteil.

Richtiger Ansatz

Hier ist ein npm-Skript, das die Qualität des Codes überprüft. Das Durchführen von Überprüfungen wird parallelisiert. Das Skript wird ausgeführt, wenn versucht wird, neuen Code an das Repository zu senden. Darüber hinaus kann der Entwickler es von sich aus starten.

 "scripts": {   "inspect:sanity-testing": "mocha **/**--test.js --grep \"sanity\"",   "inspect:lint": "eslint .",   "inspect:vulnerabilities": "npm audit",   "inspect:license": "license-checker --failOn GPLv2",   "inspect:complexity": "plato .",     "inspect:all": "concurrently -c \"bgBlue.bold,bgMagenta.bold,yellow\" \"npm:inspect:quick-testing\" \"npm:inspect:lint\" \"npm:inspect:vulnerabilities\" \"npm:inspect:license\"" }, "husky": {   "hooks": {     "precommit": "npm run inspect:all",     "prepush": "npm run inspect:all"   } } 

▍24. Führen Sie End-to-End-Tests an einem realistischen Spiegel der Produktionsumgebung durch

Empfehlungen

In dem riesigen Kubernetes-Ökosystem besteht immer noch Konsens darüber, Tools zu verwenden, die für die Bereitstellung lokaler Umgebungen geeignet sind, obwohl solche Tools häufig vorkommen. Ein möglicher Ansatz besteht darin, ein „minimiertes“ Kubernet mit Tools wie Minikube oder MicroK8s auszuführen , mit denen Sie leichtgewichtige Umgebungen erstellen können, die echten Umgebungen ähneln. Ein anderer Ansatz besteht darin, Projekte in einer entfernten „echten“ Kubernetes-Umgebung zu testen. Einige CI-Anbieter (wie Codefresh ) ermöglichen die Interaktion mit integrierten Umgebungen von Kubernetes, was die Arbeit von CI-Pipelines beim Testen realer Projekte vereinfacht. In anderen Fällen können Sie mit Remote-Kubernetes-Umgebungen arbeiten.

Folgen der Abweichung von den Empfehlungen

Der Einsatz verschiedener Technologien in Produktion und Test erfordert die Unterstützung von zwei Entwicklungsmodellen und führt zur Trennung von Teams aus Programmierern und DevOps-Spezialisten.

Richtiger Ansatz

Hier ist ein Beispiel für eine CI-Kette, die, wie sie sagen, im laufenden Betrieb einen Kubernetes-Cluster erstellt (dies wird von hier übernommen ).

 deploy: stage: deploy image: registry.gitlab.com/gitlab-examples/kubernetes-deploy script: - ./configureCluster.sh $KUBE_CA_PEM_FILE $KUBE_URL $KUBE_TOKEN - kubectl create ns $NAMESPACE - kubectl create secret -n $NAMESPACE docker-registry gitlab-registry --docker-server="$CI_REGISTRY" --docker-username="$CI_REGISTRY_USER" --docker-password="$CI_REGISTRY_PASSWORD" --docker-email="$GITLAB_USER_EMAIL" - mkdir .generated - echo "$CI_BUILD_REF_NAME-$CI_BUILD_REF" - sed -e "s/TAG/$CI_BUILD_REF_NAME-$CI_BUILD_REF/g" templates/deals.yaml | tee ".generated/deals.yaml" - kubectl apply --namespace $NAMESPACE -f .generated/deals.yaml - kubectl apply --namespace $NAMESPACE -f templates/my-sock-shop.yaml environment: name: test-for-ci 

▍25. Bemühen Sie sich, die Testausführung zu parallelisieren

Empfehlungen

Wenn das Testsystem gut organisiert ist, wird es 24 Stunden am Tag zu Ihrem treuen Freund, der bereit ist, Probleme mit dem Code zu melden. Dazu müssen Tests sehr schnell durchgeführt werden. In der Praxis stellt sich heraus, dass das Ausführen von 500 Unit-Tests im Single-Threaded-Modus, bei denen der Prozessor intensiv genutzt wird, zu lange dauert. Und solche Tests müssen ziemlich oft durchgeführt werden. Glücklicherweise können moderne Tools zum Ausführen von Tests ( Jest , AVA , eine Erweiterung für Mocha ) und CI-Plattformen Tests mit mehreren Prozessen parallel ausführen, was die Geschwindigkeit des Empfangs von Testberichten erheblich verbessern kann. Einige CI-Plattformen wissen sogar, wie Tests zwischen Containern parallelisiert werden, was die Rückkopplungsschleife weiter verbessert. Um die Ausführung lokaler oder entfernter Tests erfolgreich zu parallelisieren, sollten die Tests nicht voneinander abhängig sein. Standalone-Tests können problemlos in verschiedenen Prozessen ausgeführt werden.

Folgen der Abweichung von den Empfehlungen

Das Abrufen von Testergebnissen eine Stunde nach dem Senden des Codes an das Repository während der Arbeit an neuen Projektfunktionen ist eine hervorragende Möglichkeit, den Nutzen von Testergebnissen zu verringern.

Richtiger Ansatz

Dank der parallelen Ausführung von Tests umgehen die Mokka-Parallel-Test- Bibliothek und das Jest- Framework Mokka leicht ( dies ist die Quelle dieser Informationen).


Tools zum Testen der Leistungstests

▍26. Schützen Sie sich vor rechtlichen Problemen, indem Sie die Lizenzüberprüfung und die Plagiatscodeüberprüfung verwenden

Empfehlungen

Vielleicht sind Sie jetzt nicht besonders besorgt über Probleme mit dem Gesetz und Plagiate. Überprüfen Sie Ihr Projekt jedoch auf ähnliche Probleme. Es stehen viele Tools zur Verfügung, um solche Inspektionen zu organisieren. Dies sind beispielsweise Lizenzprüfer und Plagiatsprüfer (dies ist ein kommerzielles Paket, es besteht jedoch die Möglichkeit seiner kostenlosen Verwendung). Es ist einfach, solche Überprüfungen in die CI-Pipeline zu integrieren und das Projekt beispielsweise auf das Vorhandensein von Abhängigkeiten mit begrenzten Lizenzen oder auf das Vorhandensein von Code zu überprüfen, der von StackOverflow kopiert wurde und möglicherweise die Urheberrechte anderer verletzt.

Folgen der Abweichung von den Empfehlungen

Der Entwickler kann das Paket ganz versehentlich mit einer Lizenz verwenden, die für sein Projekt nicht geeignet ist, oder den Handelscode kopieren, was zu rechtlichen Problemen führen kann.

Richtiger Ansatz

Installieren Sie das Lizenzprüfungspaket lokal oder in einer CI-Umgebung:

 npm install -g license-checker 

Wir werden die Lizenzen damit überprüfen. Wenn er etwas findet, das nicht zu uns passt, erkennen wir die Prüfung als nicht erfolgreich an. Wenn das CI-System beim Überprüfen der Lizenzen feststellt, dass ein Fehler aufgetreten ist, stoppt es die Projektzusammenstellung.

 license-checker --summary --failOn BSD 

Lizenzprüfung

▍27. Überprüfen Sie das Projekt ständig auf anfällige Abhängigkeiten

Empfehlungen

Selbst hoch angesehene und zuverlässige Pakete wie Express weisen Schwachstellen auf. Um solche Schwachstellen zu identifizieren, können Sie spezielle Tools verwenden - wie das Standardtool zum Prüfen von npm-Paketen oder das kommerzielle snyk- Projekt mit einer kostenlosen Version. Diese Überprüfungen können zusammen mit anderen Teil der CI-Pipeline sein.

Folgen der Abweichung von den Empfehlungen

Um Ihr Projekt vor Schwachstellen seiner Abhängigkeiten zu schützen, ohne spezielle Tools zu verwenden, müssen Sie Veröffentlichungen über solche Schwachstellen ständig überwachen. Dies ist eine sehr zeitaufwändige Aufgabe.

Richtiger Ansatz

Hier sind die Ergebnisse der Projektüberprüfung mit NPM Audit.


Paketbericht zur Überprüfung der Sicherheitsanfälligkeit

▍28. Automatisieren Sie Abhängigkeitsaktualisierungen

Empfehlungen

Der Weg zur Hölle ist mit guten Absichten gepflastert. Diese Idee ist vollständig auf die package-lock.json anwendbar, deren Verwendung standardmäßig Paketaktualisierungen blockiert. Dies geschieht auch in Fällen, in denen Projekte durch die Befehle npm install und npm update in einen fehlerfreien Zustand versetzt werden. Dies führt entweder bestenfalls zur Verwendung veralteter Pakete oder im schlimmsten Fall zum Auftreten von anfälligem Code im Projekt. Die Entwicklungsteams verlassen sich daher entweder auf die manuelle Aktualisierung von Informationen über geeignete Versionen von Paketen oder auf Dienstprogramme wie ncu , die wiederum manuell gestartet werden. Das Aktualisieren von Abhängigkeiten wird am besten automatisiert, wobei der Schwerpunkt auf der Verwendung der zuverlässigsten Versionen der im Projekt verwendeten Pakete liegt. Dies ist nicht die einzig richtige Lösung. Bei der Automatisierung von Paketaktualisierungen gibt es jedoch einige bemerkenswerte Ansätze. Die erste besteht darin , Pakete wie das Überprüfen von Paketen mit npm-veralteten oder npm-check-Updates (ncu) in die CI-Pipeline einzufügen. Dies hilft dabei, veraltete Pakete zu identifizieren und Entwickler zu ermutigen, sie zu aktualisieren. Der zweite Ansatz besteht darin, kommerzielle Tools zu verwenden, die den Code überprüfen und automatisch Pull-Anforderungen stellen, um Abhängigkeiten zu aktualisieren. Im Bereich der automatischen Abhängigkeitsaktualisierung stehen wir vor einer weiteren interessanten Frage bezüglich der Aktualisierungsrichtlinie. Wenn das Update mit jedem neuen Patch aktualisiert wird, wird das System möglicherweise zu stark belastet. Wenn Sie unmittelbar nach der Veröffentlichung der nächsten Hauptversion des Pakets aktualisieren, kann dies zur Verwendung instabiler Lösungen im Projekt führen (Schwachstellen in vielen Paketen werden bereits in den ersten Tagen nach der Veröffentlichung gefunden, lesen Sie den Vorfall mit eslint-scope). Eine gute Paketaktualisierungsrichtlinie kann eine gewisse „Übergangszeit“ vorsehen, wenn die lokale Version nicht unmittelbar nach der Veröffentlichung der nächsten neuen Version, jedoch mit einer gewissen Verzögerung, als veraltet angesehen wird. , 1.3.1, 1.3.2, 1.3.8.

, , , .

ncu , , , .


ncu

▍29. , Node.js

Empfehlungen

, Node.js-, , Node.js .

1. . — , , , Jenkins .
2. , Docker.
3. . , , . (, ), , , , .
4. , , , . — , , , .
5. , . , feature, — master, , ( ).
6. . , .
7. .
8. (, Docker) .
9. , , , . , node_modules .

, , .

▍30.

Empfehlungen

, . , , , Node.js , . CI-, , « ». , , , . , , mySQL, — Postgres. , Node.js, — 8, 9 10. , . CI-.

, , , . , , .

CI- Travis Node.js.

 language: node_js node_js: - "7" - "6" - "5" - "4" install: - npm install script: - npm run test 

Zusammenfassung

, , . , , .

Liebe Leser! ?