Améliorer le flux CI/CD pour votre application

Les grandes entreprises technologiques ont la capacité de faire des milliers de versions par jour. Déjà en 2011, Amazon a publié un nouveau logiciel une fois par11,6 secondes . Ces entreprises ont généralement des équipes entières travaillant à améliorer la vitesse de livraison de leurs équipes de produits. Heureusement, bon nombre des meilleures pratiques utilisées dans ces entreprises technologiques sont bien documentées et disposent d'outils open source disponibles pour chaque équipe afin d'atteindre les mêmes performances de livraison que les grandes entreprises technologiques.

Dans cet article, nous allons passer en revue quelques concepts qui peuvent être combinés pour créer un flux CI/CD moderne pour votre logiciel. Nous utiliserons GitHub Actions et les packages NPM comme base, mais les outils et concepts peuvent être appliqués à n'importe quel langage. Je les ai utilisés pour publier avec succès des packages Python et des conteneurs Docker.

Flux GitHub

Flux GitHub est un modèle de branchement léger suggéré par GitHub. Pour la plupart des entreprises et des équipes, cela est plus que suffisant et convient parfaitement au code modularisé et aux microservices. Les équipes qui ont décidéGitflowne s'exécutent souvent pas dans les cas extrêmes ou les situations pour lesquelles le flux complet offre des solutions (par exemple, correctifs, plusieurs versions actives du logiciel).

Les règles sont simples :

• principaleest toujours libérable ;
• Succursale deprincipalepour introduire un changement (nouvelle fonctionnalité, correction de bogue, etc.) ;
• Une fois qu'une branche est terminée, créez une demande d'extraction ;
• Une fois la demande d'extraction approuvée, fusionnez-la avecprincipale;
• Pour créer une release, taguez simplementprincipale.

Cette stratégie fonctionne bien lorsque votre équipe adopte des branches éphémères et limite la portée des changements. Si vous choisissez de travailler sur des fonctionnalités plus importantes et de conserver des branches plus longtemps, vous aurez du mal à résoudre périodiquement les conflits de fusion.

En créant souvent des releases, vousréduire la portée des changements , et donc le risque de problèmes après un nouveau déploiement. Cela réduira également la nécessité de créer des versions de correctifs, car celles-ci peuvent être gérées dans le flux de développement normal. Étant donné que la portée des modifications des versions est faible et que votre rythme de livraison est rapide, il n'est souvent pas nécessaire d'avoir des branches de version distinctes pour les corrections de bogues.

Version sémantique

La gestion sémantique des versions est une stratégie de numérotation des versions pour communiquer la portée de la modification de votre nouvelle version.

La version de publication est spécifiée sous la forme suivante :vX.YZ

• X: cette version introduit une modification avec rupture.
• ET: cette version introduit une nouvelle fonctionnalité.
• AVEC: cette version introduit un correctif ou un autre changement non visible.

En vérifiant le numéro de version, les autres peuvent rapidement estimer l'impact de la nouvelle version et décider s'ils doivent automatiquement mettre à jour vers votre nouvelle version ou prévoir du temps pour gérer les changements de rupture.

Engagements conventionnels

Commits conventionnels sont, comme leur nom l'indique, une convention sur la façon de structurer vos messages de validation. Le modèle de cette convention ressemble à ceci :

[optional scope]:

[optional body]

[optional footer]

Quelques exemples pratiques :

corvée : ajouter des actions GitHub pour les demandes de fusion

correction : gérer les corps de publication vides

exploit : ajouter une liste déroulante pour spécifier la devise

La spécification permet une certaine flexibilité vis-à-vis des types, mais les plus importants sont les suivants :

• réparer
  Cette modification corrige un bogue.
• exploit
  Cette modification introduit une nouvelle fonctionnalité ou résout une user story.
• CHANGEMENT RUPTURE
  Cette modification introduit une modification avec rupture et entraîne des actions requises pour les utilisateurs de ce logiciel.

Version standard

Quel est l'intérêt des commits conventionnels, vous vous demandez peut-être. En général, l'utilisation de conventions vous permet de créer des outils et de l'automatisation. C'est également le cas pour les commits conventionnels. Par exemple, vous pouvez générer automatiquement des notes de version et augmenter la version de votre package.Version standardest un outil qui le fait automatiquement pour vous.

La version Standard analyse votre journal Git dans le but suivant :

• Génération des notes de version ;
• Détermination de la prochaine version basée sur les balises Git ;
• Cogner votrepackage.jsonversion;
• Créer un commit qui inclut vos notes de version etpackage.jsonbosse de version ;
• Marquage du commit.

Pour installer la version standard, vous pouvez utiliser NPM :

npm i -D version standard

Vous pouvez ensuite l'ajouter à votrepackage.jsonsous forme de scénario :

{ "scripts": { "release": "version-standard" } }

Ou, alternativement, utilisez npx :

npx version standard

Lorsque vous souhaitez créer une version, vous pouvez simplement exécuterversion d'exécution npm , et la version standard se chargera du reste. En règle générale, vous configurerez votre pipeline CI/CD pour effectuer ces tâches à votre place.

Si vous voulez aller vite, vous pouvez configurer votre pipeline pourcréer une release chaque fois qu'une pull request est fusionnée dans votre base de code. Dans ce cas, vous devez faire attention à ce que votre pipeline ne crée pas une boucle de construction infinie, car l'outil validera et transmettra les modifications à lui-même. Dans GitHub Actions, vous pouvez inclure une balise[skip ci] dans vos messages de commit afin de dire à GitHub de ne pas déclencher de build CI pour un certain commit. Vous pouvez configurer une version Standard pour inclure le[skip ci] balise dans sa configuration danspackage.json:

"standard-version": { "releaseCommitMessageFormat": "chore(release): {{currentTag}}[skip ci]" }

Actions GitHub

Si vous utilisez GitHub, vous pouvez utiliser la fonctionnalité d'automatisation du travail intégrée appeléeActions GitHub . GitHub Actions peut être utilisé comme service CI/CD en incluant un fichier de configuration YAML dans un.github/flux de travailrépertoire à la racine de votre dépôt.

PourExemplevous pouvez créer un fichier.github/workflows/learn-github-actions.ymlavec le contenu suivant :

nom : learn-github-actions sur :[push]jobs : check-bats-version : runs-on : ubuntu-latest steps : - uses : actions/checkout@v2 - uses : actions/setup-node@v2 with : node-version : '14' - run : npm install - g chauves-souris - courir : chauves-souris -v

Les actions GitHub peuvent être configurées pour s'autoriser à valider et à repousser les modifications apportées à votre référentiel. Pour ce faire, il vous suffit d'exécuterconfiguration gitdans votre flux de travail :

 - nom : setup git config run : |  git config user.name "GitHub Actions Bot" git config user.email "<>" - run: ... - run: git push --follow-tags origin main

Mettre tous ensemble

La combinaison de tous ces concepts aboutira àun flux de publication hautement automatisé pour votre référentiel. La configuration de l'outillage se compose principalement de deux sources :

1. package.json
2. .github/workflows/

C'est ainsi que lepackage.jsonfichier ressemble (y compris[skip ci] configuration):

{ "name": "cicd-demo", "version": "1.0.4", "description": "", "main": "hello-world.js", "scripts": { "release": " standard-version" }, "repository": { "type": "git", "url": "git+https://github.com/Intellicode/cicd-demo.git" }, "author": "Tom Hastjarjanto", "license": "ISC", "bugs": { "url": "https://github.com/Intellicode/cicd-demo/issues" }, "homepage": "https://github. com/Intellicode/cicd-demo#readme", "dependencies": { "standard-version": "^9.3.2" }, "standard-version": { "releaseCommitMessageFormat": "chore(release): {{currentTag }}[skip ci]" } }

Et voici le flux de travail GitHub Actions qui s'exécute sur un push toprincipale:

nom : Relâchez sur poussez sur : poussez : branches :[ main ]jobs: build: runs-on: ubuntu-latest strategy: matrix: node-version:[16.x] étapes : - utilise : actions/checkout@v2 - nom : utilise Node.js ${{ matrix.node-version }} utilise : actions/setup-node@v2 avec : node-version : ${{ matrix.node-version }} }} cache : 'npm' - exécuter : npm ci - exécuter : npm run build --if-present - nom : setup git config exécuter : |  git config user.name "GitHub Actions Bot" git config user.email "<>" - exécuter : npm run release - exécuter : git push --follow-tags origin main

Ceversion d'exécution npmfera ce qui suit :

• mise à jourCHANGELOG.mdavec de nouvelles notes de version depuis la dernière version ;
• déterminer la prochaine version en fonction des balises Git ;
• te cognerpackage.jsonversion;
• créer un commit qui inclut vos notes de version etpackage.jsonbosse de version ;
• taguer le commit.

git push --follow-tags origine principalefinalisera la version :

• Il pousse la balise nouvellement créée vers votre référentiel.
• Il met à jourprincipaleavec les modifications effectuées danspackage.jsonetCHANGELOG.md.

Noter:Un exemple complet est disponible dansmon référentiel d'exemple.

Conclusion

Nous avons exploré quelques concepts qui, lorsqu'ils sont combinés, peuvent aboutir à une configuration automatisée efficace de votre procédure de publication. Avec cette configuration, vous pourrez diffuser plusieurs fois par heure avecune trace entièrement documentée gérée par Git . Pour profiter pleinement de la configuration et de la publication avec un maximum de confiance, il est fortement recommandé de disposer d'une suite de tests robuste qui s'exécute sur l'intégration.

Si la libération à chaque fusion est une étape trop loin, vous pouvez adapter la configuration pour qu'elle soit effectuée manuellement.

Lectures complémentaires sur SmashingMag

(vf, yk, il)