Ich möchte sofort reservieren: Dieser Artikel enthält kein gebrauchsfertiges Rezept. Es ist eher meine Geschichte von Reisen in die Welt von Typescript und NodeJS sowie die Ergebnisse meiner Experimente. Am Ende des Artikels befindet sich jedoch ein Link zum GitLab-Repository, den Sie sehen und vielleicht etwas für sich nehmen können. Vielleicht erstellen Sie sogar nach meiner Erfahrung Ihre eigene automatisierte Lösung.

Warum ist es notwendig?

Warum müssen Sie überhaupt Bibliotheken oder in einem bestimmten Fall NPM-Pakete erstellen?

1. Wiederverwenden von Code zwischen Projekten.
   
   Alles begann mit der Tatsache, dass ich die Gewohnheit bemerkte, einen Ordner / Werkzeuge in Projekten zu erstellen. Außerdem nehme ich den größten Teil dieses Ordners mit, wenn ich zu einem neuen Projekt wechsle. Und dann stellte ich mir die Frage, warum nicht ein NPM-Paket anstelle von Copy Paste erstellen und es dann einfach mit einem beliebigen Projekt verbinden?
2. Unterschiedlicher Lebenszyklus. In einer der Anwendungen gab es eine große Unternehmensgruppe von Komponenten als Abhängigkeit. Es war möglich, es nur vollständig zu aktualisieren, selbst wenn nur eine Komponente aktualisiert wurde. Änderungen an anderen Komponenten könnten etwas beschädigen, und wir hatten nicht immer genug geschätzte Zeit, um es erneut zu testen. Dieses Modell ist sehr unpraktisch. Wenn jedes Paket seinen Zweck oder eine kleine Reihe verwandter Ziele erfüllt, können sie bereits aktualisiert werden, wenn es wirklich benötigt wird. Außerdem werden die folgenden Versionen des Pakets nur veröffentlicht, wenn sie einige Änderungen aufweisen, und nicht "für das Unternehmen".
3. Trennen Sie kleinen Code von der Kerngeschäftslogik. DDD hat das Prinzip der Domänendestillation: Es beinhaltet die Identifizierung von Codeteilen, die nicht zur Hauptdomäne gehören, und die Isolierung von diesen. Und wie ist es besser zu isolieren, als diesen Code in ein separates Projekt zu übernehmen?
   Übrigens ist die Domänendestillation dem SRP-Prinzip nur auf einer anderen Ebene sehr ähnlich.
4. Eigene Codeabdeckung. In einem der Projekte, an denen ich teilgenommen habe, lag die Codeabdeckung bei etwa 30%. Und die Bibliothek, die ich herausgenommen habe, hat eine Abdeckung von ungefähr 100%. Obwohl das Projekt den Prozentsatz der Abdeckung verlor, da es sich vor dem Entfernen in der roten Zone befand, blieb es bestehen. Und die Bibliothek hat bis heute nach fast einem Jahr und 4 Hauptversionen solche beneidenswerten Indikatoren.
5. Open Source Code, der keine Geschäftslogik enthält, ist der erste Kandidat für die Trennung vom Projekt, sodass er geöffnet werden kann.

Neue Bibliotheken "teuer" starten

Es gibt ein solches Problem: Um eine Bibliothek zu erstellen, reicht es nicht aus, ein Git-Repository darunter zu haben. Sie müssen die Aufgabe auch so konfigurieren, dass das Projekt zusammengestellt, statische Überprüfungen (Flusen) und Tests durchgeführt werden können. Zusätzlich zum Testen ist es ratsam, die Codeabdeckung zu erfassen. Außerdem müssen Sie das Paket jedes Mal manuell veröffentlichen. Und müssen noch Readme schreiben. Das ist nur mit Readme kann ich nicht helfen.

Was kann man also mit all diesen langweiligen, uninteressanten Aufgaben machen?

Erster Schritt: Samen

Ich habe zunächst ein Seed-Projekt erstellt. Es ist eine Art Starter-Kit, es hatte die gleiche Struktur wie mein erstes Projekt, bei dem der Code in einem separaten Paket zusammengefasst wurde. Ich habe darin Gulp-Aufgaben und Skripte erstellt, mit denen die Paketabdeckung in einer Aktion erstellt, getestet und gesammelt werden kann. Um ein weiteres Projekt zu erstellen, musste ich Seed in einen neuen Ordner klonen und den Ursprung ändern, damit er auf das frisch erstellte Repository auf GitHub verweist (dann habe ich immer noch GitHub verwendet).

Diese Art der Erstellung von Projekten bietet einen weiteren Vorteil. Jetzt werden Änderungen bezüglich des Aufbaus oder Testens des Projekts einmal im Seed-Projekt vorgenommen. Das Kopieren und Einfügen dieser Änderungen ist nicht mehr erforderlich. Stattdessen erstelle ich im letzten Projekt, wenn ich das nächste Mal damit arbeiten muss, eine zweite Fernbedienung namens seed und übernehme diese Änderungen von dort.

Und es hat eine Weile bei mir funktioniert. Bis ich Seed in einem Projekt verwendet habe, an dem mehrere Entwickler teilgenommen haben. Ich habe eine Anweisung in drei Schritten geschrieben: Nimm den letzten Master, erstelle und veröffentliche. Und irgendwann hat einer der Entwickler aus irgendeinem Grund den ersten und den dritten Schritt abgeschlossen. Wie ist das überhaupt möglich?

Zweiter Schritt: Automatische Veröffentlichung

Trotz der Tatsache, dass es sich um einen einzelnen Fehler handelte, sind manuelle Aktionen wie das Veröffentlichen langweilig. Daher dachte ich, dass es notwendig ist, es zu automatisieren. Darüber hinaus wurde CI benötigt, um zu verhindern, dass rote Commits in den Master gelangen. Zuerst habe ich versucht, Travis CI zu verwenden, bin aber auf die folgende Einschränkung gestoßen. Er betrachtet Pull-Request im Master als gleichbedeutend mit einem Commit im Master. Und ich musste verschiedene Dinge tun.

Einer meiner Kollegen riet mir, auf GitLab und sein CI zu achten, und alles, was ich wollte, funktionierte dort.

Ich habe den folgenden Prozess für die Arbeit mit dem Projekt erstellt, der verwendet wird, wenn Sie einen Fehler beheben, neue Funktionen hinzufügen oder eine neue Version erstellen müssen:

1. Ich erstelle einen Zweig vom Master. Ich schreibe Code und teste darin.
2. Ich erstelle eine Zusammenführungsanforderung.
3. GitLab CI führt automatisch Tests in einem Knoten aus: dem neuesten Container
4. Die Anforderung besteht die Codeüberprüfung.
5. Nachdem die Anforderung eingefroren wurde, führt GitLab den zweiten Satz von Skripten aus. Dieser Satz erstellt beim Festschreiben ein Tag mit der Versionsnummer. Die Versionsnummer wird aus package.json übernommen. Wenn sie dort manuell erhöht wird, wird die zuletzt veröffentlichte Version übernommen und automatisch inkrementiert.
6. Das Skript erstellt das Projekt und führt die Tests erneut aus.
7. In den letzten Schritten wird das Versions-Tag an das Repository gesendet und das Paket in NPM veröffentlicht.

Daher stimmt die im Tag angegebene Version immer mit der Version des Pakets überein, die von diesem Commit veröffentlicht wurde. Damit diese Vorgänge funktionieren, müssen Sie Umgebungsvariablen mit Zugriffsschlüsseln für das Repository und NPM im GitLab-Projekt angeben.

Letzter Schritt: Alles automatisieren

Zu diesem Zeitpunkt habe ich bereits viel automatisiert, aber es gab immer noch viele manuelle Aktionen, um ein Projekt zu erstellen. Dies war natürlich ohnehin schon ein Fortschritt, da die Aktionen einmal pro Projekt und nicht bei jeder Version durchgeführt wurden. Trotzdem bestand die Anweisung aus 11 Schritten. Und ich selbst habe mich ein paar Mal geirrt, als ich diese Schritte unternommen habe. Dann habe ich beschlossen, dass ich dies zu Ende bringen muss, seit ich mit der Automatisierung begonnen habe.

Damit diese vollständige Automatisierung funktioniert, muss der Computer 3 Dateien im Ordner .ssh haben. Ich dachte, dass dieser Ordner ziemlich geschützt ist, da der private Schlüssel id_rsa bereits dort gespeichert ist. Diese Datei wird auch verwendet, damit GitLab CI Tags an das Repository übergeben kann.

Die zweite Datei, die ich dort ablege, ist "gitlab". Sie enthält den Zugriffsschlüssel für die GitLab-API. Die dritte Datei ist "npm", der Zugriffsschlüssel für die Veröffentlichung des Pakets.

Und dann beginnt die Magie. Um ein neues Paket zu erstellen, müssen Sie lediglich einen Befehl im Seed-Ordner ausführen: "gulp startNewLib -n [npmName] / [libName]". Fertig, das Paket wird erstellt und kann entwickelt und automatisch veröffentlicht werden.

Auf diese Weise wurde beispielsweise das Paket "vlr / Gültigkeit" erstellt.

Dieser Befehl führt Folgendes aus:

1. Erstellt ein Projekt auf GitLab
2. Klont Seed in einen lokalen Ordner neben dem Ordner, in dem der Befehl ausgeführt wird.
3. Ändert den Ursprung des in Schritt 1 erstellten Projekts
4. Schieben Sie den Hauptzweig
5. Erstellt Umgebungsvariablen in einem Projekt aus Dateien in einem .ssh-Ordner
6. Erstellt einen firstImplementation-Zweig
7. Ändert den Namen der Bibliothek in package.json, schreibt den Zweig fest und pusht ihn

Danach müssen Sie nur noch den Code dort ablegen und eine Zusammenführungsanforderung erstellen.

Infolgedessen dauert es ungefähr fünf Minuten, worauf man stolz sein kann, von dem Moment an, in dem entschieden wird, eine Art Code in ein separates Projekt einzufügen, bis die erste Version veröffentlicht wird. Vier von ihnen belegen zwei GitLabCI-Pipelines, und eine Minute, um den obigen Befehl zu starten, ziehen Sie den Code per Drag & Drop und klicken Sie auf die Schaltflächen in der GitLab-Oberfläche, um die Anforderung zu erstellen und dann zu halten.

Es gibt einige Einschränkungen: Der GitLab-Name muss mit dem Namen in npm übereinstimmen. Im Gegensatz zu den übrigen Funktionen im Seed-Projekt funktioniert dieser Befehl jedoch nur unter Windows.

Wenn Sie an diesem Seed-Projekt interessiert sind, können Sie es unter folgendem Link studieren .