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 par 11,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 :

• main est toujours libérable ;
• Succursale de main pour 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 avec main;
• Pour créer une release, taguez simplement main.

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, vous ré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.Y.Z

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

En vérifiant le numéro de version, d’autres peuvent rapidement estimer l’impact de la nouvelle version et décider s’ils doivent automatiquement mettre à jour 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 :

<type>[optional scope]: <description>

[optional body]

[optional footer]

Quelques exemples pratiques :

chore: add GitHub actions for merge requests

fix: handle empty post bodies

feat: add dropdown to specify currency

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

• fix
  Cette modification corrige un bogue.
• feat
  Cette modification introduit une nouvelle fonctionnalité ou résout une user story.
• BREAKING CHANGE
  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 standard est 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 votre package.json version;
• Créer un commit qui inclut vos notes de version et package.json bosse de version ;
• Marquage du commit.

Pour installer la version standard, vous pouvez utiliser NPM :

npm i -D standard-version

Vous pouvez ensuite l’ajouter à votre package.json sous forme de scénario :

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

Ou, alternativement, utilisez npx :

npx standard-version

Lorsque vous souhaitez créer une version, vous pouvez simplement exécuter npm run release, 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 pour cré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 dans package.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ée Actions GitHub. GitHub Actions peut être utilisé comme service CI/CD en incluant un fichier de configuration YAML dans un .github/workflows répertoire à la racine de votre dépôt.

Pour Exemplevous pouvez créer un fichier .github/workflows/learn-github-actions.yml avec le contenu suivant :

name: learn-github-actions
on: [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 bats
      - run: bats -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écuter git config dans votre flux de travail :

- name: 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/<your-workflow.yml>

C’est ainsi que le package.json fichier 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 to main:

name: Release on push

on:
  push:
    branches: [ main ]

jobs:
  build:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node-version: [16.x]
    steps:
    - uses: actions/checkout@v2
    - name: Use Node.js ${{ matrix.node-version }}
      uses: actions/setup-node@v2
      with:
        node-version: ${{ matrix.node-version }}
        cache: 'npm'
    - run: npm ci
    - run: npm run build --if-present
    - name: setup git config
      run: |
          git config user.name "GitHub Actions Bot"
          git config user.email "<>"
    - run: npm run release
    - run: git push --follow-tags origin main

Cette npm run release fera ce qui suit :

• mise à jour CHANGELOG.md avec de nouvelles notes de version depuis la dernière version ;
• déterminer la prochaine version en fonction des balises Git ;
• te cogner package.json version;
• créer un commit qui inclut vos notes de version et package.json bosse de version ;
• taguer le commit.

git push --follow-tags origin main finalisera la version :

• Il pousse la balise nouvellement créée vers votre référentiel.
• Il met à jour main avec les modifications effectuées dans package.json et CHANGELOG.md.

Noter: Un exemple complet est disponible dans mon 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 avec une 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)