Je souhaite réserver tout de suite: cet article ne donne pas de recette prête à l'emploi. C'est plutôt mon histoire de voyager dans le monde de Typescript et NodeJS, ainsi que les résultats de mes expériences. Néanmoins, à la fin de l'article, il y aura un lien vers le référentiel GitLab, que vous pouvez voir, et peut-être prendre quelque chose que vous aimez par vous-même. Peut-être même d'après mon expérience, créer votre propre solution automatisée.

Pourquoi est-ce nécessaire

Alors, pourquoi avez-vous besoin de créer des bibliothèques ou, dans un cas particulier, des packages NPM?

1. Réutilisation du code entre les projets.
   
   Tout a commencé avec le fait que j'ai remarqué l'habitude de créer un dossier / outils dans les projets. De plus, j'emporte également la plupart de ce dossier avec moi lorsque je passe à un nouveau projet. Et puis je me suis posé une question, pourquoi ne pas créer un package NPM au lieu de copier-coller et ensuite le connecter à n'importe quel projet?
2. Cycle de vie différent. Dans l'une des applications, il y avait un grand assemblage d'entreprise de composants comme dépendance. Il n'a été possible de le mettre à jour que dans son intégralité, même si un seul composant a été mis à jour. Les changements dans d'autres composants pourraient casser quelque chose et nous n'avons pas toujours eu suffisamment de temps estimé pour le retester. Ce modèle est très gênant. Lorsque chaque package sert son objectif ou un petit ensemble d'objectifs connexes, ils peuvent déjà être mis à jour lorsque cela est vraiment nécessaire. En outre, les versions suivantes du package ne sont publiées que lorsqu'elles ont été modifiées, et non "pour l'entreprise".
3. Séparez le code mineur de la logique métier principale. DDD a le principe de la distillation de domaine; il s'agit d'identifier des morceaux de code qui n'appartiennent pas au domaine principal et de s'en isoler. Et comment est-il préférable d'isoler que de prendre ce code dans un projet distinct.
   Soit dit en passant, la distillation de domaine est très similaire au principe SRP uniquement à un niveau différent.
4. Couverture de code propre. Dans l'un des projets auxquels j'ai participé, la couverture du code était d'environ 30%. Et la bibliothèque que j'ai retirée a une couverture d'environ 100%. Le projet, bien qu'il ait perdu le pourcentage de couverture, car il était dans la zone rouge avant le retrait, il est resté. Et la bibliothèque a de tels indicateurs enviables à ce jour, après près d'un an et 4 versions majeures.
5. Open source Le code qui ne contient pas de logique métier est le premier candidat à la séparation du projet, il peut donc être rendu ouvert.

Lancer de nouvelles bibliothèques «chères»

Il y a un tel problème: pour créer une bibliothèque, il ne suffit pas d'avoir un dépôt git en dessous. Vous devez également configurer la tâche afin que le projet puisse être assemblé, effectuer une vérification statique (peluches) et un test. De plus, en plus des tests, il est conseillé de collecter la couverture du code. De plus, vous devrez publier le package manuellement à chaque fois. Et encore besoin d'écrire un readme. C'est juste avec readme que je ne peux pas aider.

Alors, que peut-on faire avec toutes ces tâches ennuyeuses et sans intérêt?

Première étape: la graine

J'ai commencé par créer un projet d'amorçage. C'est une sorte de kit de démarrage, il avait la même structure que mon premier projet pour prendre le code dans un package séparé. J'ai créé des tâches et des scripts gulp qui permettraient de créer, tester et collecter la couverture du package en une seule action. Maintenant, pour créer un autre projet, je devais cloner la graine dans un nouveau dossier et changer l'origine afin qu'elle pointe vers le référentiel fraîchement créé sur GitHub (alors j'ai toujours utilisé GitHub).

Cette façon de créer des projets offre un autre avantage. Désormais, les modifications concernant la construction ou les tests du projet sont effectuées une seule fois, dans le projet d'amorçage. Et copier-coller ces modifications n'est plus nécessaire. Au lieu de cela, dans le projet final, la prochaine fois que je dois travailler avec lui, je crée une deuxième télécommande appelée seed et j'apporte ces modifications à partir de là.

Et cela a fonctionné pour moi pendant un certain temps. Jusqu'à ce que j'utilise des graines dans un projet auquel participaient plusieurs développeurs. J'ai écrit une instruction en trois étapes: prendre le dernier master, construire et publier. Et à un moment donné, l'un des développeurs, pour une raison quelconque, a terminé la première étape et la troisième. Comment est-ce encore possible?

Deuxième étape: publication automatique

Malgré le fait qu'il s'agissait d'une seule erreur, des actions manuelles telles que la publication sont ennuyeuses. J'ai donc pensé qu'il fallait l'automatiser. De plus, CI était nécessaire pour empêcher les validations rouges de pénétrer dans le maître. Au début, j'ai essayé d'utiliser Travis CI, mais j'ai rencontré la restriction suivante. Il considère la pull-request dans master équivalente à une validation dans master. Et je devais faire des choses différentes.

Un de mes collègues m'a conseillé de faire attention à GitLab et son CI, et tout ce que je voulais y a fonctionné.

J'ai créé le processus suivant de travail avec le projet, qui est utilisé lorsque vous devez corriger un bogue, ajouter de nouvelles fonctionnalités ou créer une nouvelle version:

1. Je crée une branche depuis master. J'écris du code et des tests dedans.
2. Je crée une demande de fusion.
3. GitLab CI exécute automatiquement des tests dans un nœud: dernier conteneur
4. La demande passe l'examen du code.
5. Une fois la demande gelée, GitLab exécute le deuxième ensemble de scripts. Cet ensemble crée une balise sur la validation avec le numéro de version. Le numéro de version provient de package.json, s'il y est manuellement augmenté, sinon, la dernière version publiée est prise et incrémentée automatiquement.
6. Le script construit le projet et exécute à nouveau les tests.
7. Dans les dernières étapes, la balise de version est envoyée au référentiel et le package est publié dans NPM.

Ainsi, la version indiquée dans la balise correspond toujours à la version du package publiée à partir de ce commit. Pour que ces opérations fonctionnent, vous devez spécifier des variables d'environnement avec des clés d'accès au référentiel et NPM dans le projet GitLab.

Dernière étape: automatiser tout

À ce stade, j'avais déjà beaucoup automatisé, mais il y avait encore pas mal d'actions manuelles pour créer un projet. Ceci, bien sûr, était déjà de toute façon en cours, car les actions étaient effectuées une fois par projet, et non sur chaque version. Mais encore, l'instruction se composait de 11 étapes. Et je me suis trompé plusieurs fois en prenant ces mesures. Ensuite, j'ai décidé que depuis que j'ai commencé à automatiser, je dois mettre fin à cela.

Pour que cette automatisation complète fonctionne, mais l'ordinateur j'ai besoin d'avoir 3 fichiers dans le dossier .ssh. Je pensais que ce dossier est assez protégé, car la clé privée id_rsa y est déjà stockée. Ce fichier sera également utilisé pour permettre à GitLab CI de transmettre des balises au référentiel.

Le deuxième fichier que j'y mets est «gitlab», il contient la clé d'accès à l'API GitLab. Et le troisième fichier est «npm», la clé d'accès pour publier le package.

Et puis la magie commence. Tout ce dont vous avez besoin pour créer un nouveau package est d'exécuter une commande dans le dossier d'origine: «gulp startNewLib -n [npmName] / [libName]». Terminé, le package est créé, prêt pour le développement et la publication automatique.

Par exemple, le package "vlr / validité" a été créé de cette façon.

Cette commande effectue les opérations suivantes:

1. Crée un projet sur GitLab
2. Clone amorce dans un dossier local à côté du dossier à partir duquel la commande est exécutée.
3. Modifie l'origine du projet créé à l'étape 1
4. Poussez la branche principale
5. Crée des variables d'environnement dans un projet à partir de fichiers dans un dossier .ssh
6. Crée une première branche de mise en œuvre
7. Modifie le nom de la bibliothèque dans package.json, valide et pousse la branche

Tout ce dont vous avez besoin après cela est d'y mettre le code et de créer une demande de fusion.

Par conséquent, ce dont on peut être fier, depuis le moment où il est décidé de mettre une sorte de code dans un projet distinct jusqu'à la publication de la première version, cela prend environ cinq minutes. Quatre d'entre eux occupent deux pipelines GitLabCI, et une minute pour lancer la commande ci-dessus, faites glisser et déposez le code, puis cliquez sur les boutons de l'interface GitLab pour créer et maintenir la demande.

Il y a quelques limitations: le nom de GitLab doit correspondre au nom dans npm. Et pourtant, cette commande, contrairement au reste des fonctionnalités du projet d'origine, ne fonctionne que sous Windows.

Si vous êtes intéressé par ce projet de semences, vous pouvez l' étudier en cliquant sur le lien suivant .