Comment automatiser le versioning du projet et publier avec un déploiement continu

L'utilisation du contrôle de version sémantique peut faciliter la maintenance et la communication des changements de logiciels, mais les opérations manuelles sont lourdes. Même si vous fusionnez manuellement les PR, marquez la soumission et poussez la version, vous devez toujours rédiger une description de la version. Il existe de nombreuses étapes, une répétition élevée, du temps et de la main-d'œuvre.

Cet article expliquera comment réaliser des processus plus efficaces et automatisera entièrement les processus de libération en intégrant le versioning sémantique dans le processus de déploiement continu.

Contrôle de version sémantique

Une version sémantique est un numéro de version composé de trois nombres, tels que 1.4.10. Chaque numéro a une signification spécifique:

Modifications de version majeure (Major)

Le premier numéro indique un changement de version majeur, ce qui signifie qu'il y a un changement destructeur.

Modifications de la version mineure (mineure)

Le deuxième numéro indique un changement de version mineure, ce qui signifie que de nouvelles fonctionnalités ont été ajoutées.

Modification de la version du patch

Le troisième numéro indique un changement de version corrigée, ce qui signifie qu'un bogue est corrigé.

La version sémantique peut être comprise plus concise comme: changements destructeurs, changements fonctionnels et corrections de bogues. Cette description est plus précise et évite l'ambiguïté.

Soumettre le format d'information

Pour s'assurer que le numéro de version sémantique est correctement incrémenté et que la version correcte est publiée, un format d'information de soumission standardisé est requis. Un format d'information de soumission standardisé permet de déterminer quand incrémenter le nombre et générer facilement des instructions de publication. Ici, Angular sera utilisé pour soumettre des conventions d'information, et bien sûr, il peut également être modifié au besoin.

Le format est le suivant:

<code></code>

Chaque soumission contient le titre , le corps et la note de bas de page .

Soumettre le titre

Le titre est un must, il a un format spécial, y compris le type , la portée facultative et le sujet .

Le type de titre est un champ requis pour illustrer l'impact de la soumission sur la version suivante. Ce doit être l'un des types suivants:

• Feat : Nouvelles fonctionnalités
• Correction : correction de bogue
• Docs : changements de document
• Style : modifications qui n'affectent pas la signification du code (par exemple: espaces, formats, demi-colons manquants, etc.)
• Refactor : refactorisation de code, ni correction de bogues ni d'ajout de fonctions
• Perf : Améliorations des performances
• Test : ajouter ou corriger le test
• CHORE : modifications des processus de construction ou des outils et bibliothèques auxiliaires, tels que la génération de documents

Une portée est une propriété de regroupement qui spécifie les sous-systèmes qui se soumettent liés aux sous-systèmes, tels que les API, les tableaux de bord d'application ou les comptes d'utilisateurs, etc. Si plusieurs sous-systèmes sont modifiés par le commit, un astérisque (*) peut être utilisé à la place.

Le sujet du titre doit décrire brièvement les modifications apportées. Les règles suivantes sont requises lors de la rédaction d'un sujet:

• Utilisez des phrases impératives, présent (par exemple, "changé" au lieu de "modifié" ou "modifié").
• En minuscules de la lettre initiale.
• Aucune période (.) N'est ajoutée à la fin.
• Évitez les longueurs de sujet dépassant 80 caractères. Soumettre le corps.

Comme le thème du titre, le texte principal doit également utiliser des phrases impératives, présent. Il devrait inclure la motivation du changement et le comparer au comportement précédent.

Soumettre les notes de bas de page

La note de bas de page doit contenir des informations sur les modifications destructrices et est également l'endroit où la question citée pour cette soumission est fermée.

Les informations de changement destructrices devraient commencer par la rupture du changement: suivi d'un espace ou de deux nouvelles lignes. Les informations de soumission restantes sont là.

Format d'informations de soumission de renforcement

Dans le travail d'équipe, normaliser tout ce que tout le monde doit suivre est toujours un défi. Pour nous assurer que tout le monde utilise les mêmes critères de soumission, nous utiliserons Commizen.

Commizen est un outil de ligne de commande qui simplifie le processus d'utilisation d'un format de message de validation cohérent. Rendre le référentiel compatible avec Commizen signifie que toute personne dans l'équipe peut exécuter GIT CZ et obtenir des invites détaillées pour remplir les informations de soumission.

Générer et publier

Maintenant que nous savons que nos soumissions respectent les normes cohérentes, nous pouvons commencer à générer des versions et de libérer des notes. Pour ce faire, nous utiliserons un package appelé Semantic-Release. Il s'agit d'un package bien entretenu avec un bon support pour une variété de plates-formes d'intégration continue (CI).

La libération sémantique est la clé de notre voyage, car il effectuera toutes les étapes requises pour la sortie, notamment:

1. Confirmez la dernière version que vous avez publiée
2. Déterminez le type de publication en fonction des soumissions ajoutées depuis la dernière version
3. Générer des instructions de publication pour les soumissions ajoutées depuis la dernière version
4. Mettez à jour le fichier package.json et créez une balise git correspondant à la version nouvellement publiée
5. Pousser une nouvelle version

Tout CI est ok. Dans cet article, nous utilisons l'action GitHub car j'aime utiliser les fonctionnalités existantes de la plate-forme avant de rechercher une solution tierce.

Il existe de nombreuses façons d'installer la libération sémantique, mais nous utiliserons le CLI sémantique-libération car il fournit des opérations étape par étape. Exécutons la configuration du NPX Semantic-Release-CLI dans le terminal et remplissons l'assistant interactif.

Le script fera ce qui suit:

• Exécutez NPM AddUser avec les informations NPM fournies pour générer .npmrc.
• Créez un jeton d'accès personnel GitHub.
• Mettre à jour package.json.

Une fois la CLI terminée, elle ajoute une libération sémantique à package.json, mais elle ne l'installera pas réellement. Exécutez NPM Installer pour l'installer et d'autres dépendances de projet.

La seule chose qui reste est de configurer CI via des actions GitHub. Nous devons ajouter manuellement un flux de travail qui fonctionnera à libération sémantique. Créons un flux de travail de publication dans .github / workflows / release.yml.

 <code>name: Release on: push: branches: - main jobs: release: name: Release runs-on: ubuntu-18.04 steps: - name: Checkout uses: actions/checkout@v2 - name: Setup Node.js uses: actions/setup-node@v1 with: node-version: 12 - name: Install dependencies run: npm ci - name: Release env: GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} # If you need an NPM release, you can add the NPM_TOKEN # NPM_TOKEN: ${{ secrets.NPM_TOKEN }} run: npm run release</code>

Steffen Brewersdorff a fait un excellent travail pour introduire CI avec les actions GitHub, mais passons brièvement en revue ce qui se passe ici.

Cela attendra une poussée vers la branche principale avant que le pipeline ne soit exécuté. Vous pouvez modifier ce paramètre comme vous aimez exécuter un, deux ou toutes les branches.

 <code>on: push: branches: - main</code>

Il utilise ensuite la caisse pour tirer le référentiel et installer le nœud afin que NPM puisse être utilisé pour installer les dépendances du projet. Si c'est quelque chose que vous préférez, vous pouvez ajouter une étape de test.

 <code>- name: Checkout uses: actions/checkout@v2 - name: Setup Node.js uses: actions/setup-node@v1 with: node-version: 12 - name: Install dependencies run: npm ci # You can add a test step here # - name: Run Tests # run: npm test</code>

Enfin, laissez la libération sémantique faire toutes les opérations magiques:

 <code>- name: Release run: npm run release</code>

Poussez les modifications et affichez les actions:

Maintenant, chaque fois qu'une branche spécifiée est engagée (ou fusionnée), l'opération est exécutée et publiée avec une note de publication.

Postez une fête!

Nous avons réussi à créer un flux de travail de version sémantique CI / CD! N'est-ce pas si douloureux? La configuration est relativement simple et il n'y a aucun inconvénient à avoir un flux de travail de publication sémantique. Cela facilite le suivi.

Sémantique à libération Il existe de nombreux plug-ins qui peuvent permettre une automatisation plus avancée. Par exemple, il existe même un bot de version Slack qui peut être publié sur le canal du projet après le déploiement avec succès du projet. Pas besoin d'aller à GitHub pour trouver des mises à jour!

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!