Outil d'automatisation du contrôle de version

Bonjour à tous!

Il a toujours été intéressant de savoir quelles sont les versions des produits et comment les gérer? Comment automatiser le contrôle de version du développement? Je demande un chat.



Je m'appelle Roman. Je suis développeur dans une entreprise très intéressante Softeq, où tout le monde est une inspiration.

Lors du développement de divers outils, je me suis demandé si tous les développeurs connaissaient la version, quelle était sa signification et comment la gérer pendant le développement. Voyons donc ce qu'est le versioning.

Versioning

Le contrôle de version est le développement et la gestion de plusieurs versions de produit qui ont les mêmes fonctionnalités communes, mais qui sont améliorées, modernisées ou individualisées.
En bref, la version parle d'un changement de produit. Comment la version parle-t-elle du changement de produit?
Appelons le système de classement des caractères pour désigner une version de produit un schéma de gestion des versions. Divers schémas de version ont été créés pour suivre les versions de divers logiciels.

Versioning sémantique

Il existe de nombreux schémas de versionnage, mais nous sommes confrontés chaque jour au versioning sémantique . Pour le versionnage sémantique, il est caractéristique que les numéros de version et leur évolution transmettent la signification du contenu du code source et les modifications qui ont été appliquées d'une version à l'autre.

Voyons comment se forme le numéro de la version sémantique.



Imaginons que nous ayons un projet en développement. L'objectif principal du projet est de gérer la construction de la bibliothèque. Le projet vous permet de commander des matériaux pour la construction d'un bâtiment, de contrôler les étapes de construction d'une bibliothèque. Actuellement, l'architecture de l'application a été conçue, la mise en œuvre des tâches de base a été effectuée. Lors du test de la fonctionnalité de commande de matériaux pour la construction d'un bâtiment de bibliothèque, une erreur est détectée, bug . Une correction de bogue est effectuée et la version du correctif du projet est mise à niveau .



Le client avait une idée de la nécessité de mettre en œuvre une analyse des informations marketing dans le projet. Les développeurs ont conçu des services d'analyse de données avec compétence et rapidité, des services intégrés avec l'architecture actuelle. Une nouvelle fonctionnalité de projet a été ajoutée qui ne viole pas la compatibilité descendante . La version mineure du projet a augmenté.



Le projet a été mis en œuvre avec succès. Après un certain temps, le client a eu l'idée de développer cette technologie pour l'automatisation des affaires. Les plans à venir comprenaient des services complètement nouveaux: la formation d'une équipe de constructeurs, un réseau social interne, un échange interne de documents, etc. Les développeurs ont fait preuve d'une grande compétence et, après un certain temps, l'architecture du projet a été conçue pour résoudre les problèmes nouveaux et anciens. La nouvelle architecture du projet a apporté des modifications incompatibles en amont. La version majeure du projet a augmenté.




Nous présentons donc les versions des produits. Mais comment les gérer?
Regardons un outil d'automatisation du contrôle de version.

Versions

NPM: https://www.npmjs.com/package/versionings
GitHub: https://github.com/morozow/versionings

Le versioning est effectué à l'aide de la ligne de commande:

versionings --semver=[<semantic-version> | patch | prepatch | minor | preminor | premajor | prerelease | major] --branch=[<version-branch-name> | any-hyphen-case-less-100-characters-string] [--push] 

La version actuelle du produit est stockée à la fois dans le fichier ./package.json du projet, ainsi que dans les balises Git et la branche de mise à niveau. L'automatisation a la capacité de s'intégrer à divers outils tiers - le contrôle de version se fait via la commande CLI.

Regardons un exemple de mise à niveau d'un produit.

Actions

Un projet de la version actuelle 2.5.3 est en cours d'élaboration. Le développement d'un nouveau service projet est en cours dans la branche crm-user-service . Le développement du service a été achevé, toutes les modifications ont été engagées et une décision a été prise d'augmenter la version mineure:

 versionings --semver=minor --branch=user-service --push 

Résultat

1. Nouvelle branche: version / minor / v 2.6.0 - service utilisateur
2. Changement de version dans ./package.json : 2.5.3 -> 2.6.0
3. Valider la nouvelle version du produit dans la branche version / minor / v 2.6.0 - user-service
4. Poussez une nouvelle branche avec l'implémentation du service et une version augmentée du produit.
5. Création d'une demande d' extraction pour la branche version / minor / v 2.6.0 - service utilisateur , qui contient l'implémentation du service et la version augmentée du produit

Remarques

• Outil d'automatisation orienté vers l'environnement Unix
• Un exemple de projet de construction d'une bibliothèque est abstrait, pour une vue générale du versioning.

C'est tout :)

Une humeur productive et une belle journée!