{"id":72118,"date":"2023-08-21T14:10:02","date_gmt":"2023-08-21T13:10:02","guid":{"rendered":"https:\/\/kinsta.com\/fr\/?p=72118&preview=true&preview_id=72118"},"modified":"2023-08-22T06:12:02","modified_gmt":"2023-08-22T05:12:02","slug":"configurer-pipeline-ci-cd","status":"publish","type":"post","link":"https:\/\/kinsta.com\/fr\/blog\/configurer-pipeline-ci-cd\/","title":{"rendered":"Comment cr\u00e9er un pipeline CI\/CD avec les actions GitHub et l’API Kinsta"},"content":{"rendered":"

Dans le monde rapide du d\u00e9veloppement web<\/a>, l’int\u00e9gration et le d\u00e9ploiement continus (CI\/CD<\/a>) sont devenus des pratiques indispensables pour fournir efficacement des logiciels de haute qualit\u00e9. L’int\u00e9gration et le d\u00e9ploiement continus permettent aux d\u00e9veloppeurs d’automatiser le processus de construction, de test et de d\u00e9ploiement des modifications du code, r\u00e9duisant ainsi le risque d’erreur humaine et permettant des it\u00e9rations plus rapides.<\/p>\n

Cet article explique l’importance de la CI\/CD, comment cr\u00e9er un pipeline de CI et comment mettre en place un d\u00e9ploiement continu dans votre pipeline de CI avec l’API Kinsta<\/a> de mani\u00e8re programmatique – le tout avec les Actions GitHub dans votre d\u00e9p\u00f4t GitHub<\/a>.<\/p>\n

<\/div><\/kinsta-auto-toc>\n

Pourquoi utiliser CI\/CD ?<\/h2>\n

La plateforme d’h\u00e9bergement d’applications<\/a> de Kinsta a toujours offert une option de d\u00e9ploiement automatique, d\u00e9clench\u00e9e chaque fois qu’une modification est apport\u00e9e \u00e0 une branche sp\u00e9cifique de votre d\u00e9p\u00f4t Git h\u00e9berg\u00e9. Cependant, cela peut ne pas \u00eatre id\u00e9al pour les grands projets avec plusieurs membres de l’\u00e9quipe. De nombreux d\u00e9veloppeurs<\/a> ont tendance \u00e0 \u00e9viter d’activer le d\u00e9ploiement automatique pour diverses raisons.<\/p>\n

L’une d’entre elles est que, dans un environnement collaboratif o\u00f9 plusieurs d\u00e9veloppeurs travaillent sur le m\u00eame projet, les d\u00e9ploiements automatiques d\u00e9clench\u00e9s par la modification d’un d\u00e9veloppeur dans le d\u00e9p\u00f4t peuvent entra\u00eener une instabilit\u00e9 et des probl\u00e8mes impr\u00e9vus. En l’absence de tests et de validation appropri\u00e9s, m\u00eame une petite modification du code peut perturber le site en production, entra\u00eenant potentiellement des temps d’arr\u00eat et des exp\u00e9riences n\u00e9gatives pour les utilisateurs.<\/p>\n

C’est l\u00e0 qu’un pipeline CI\/CD entre en jeu. En cr\u00e9ant un flux de travail CI\/CD soigneusement orchestr\u00e9, les d\u00e9veloppeurs peuvent s’assurer que les modifications du code sont test\u00e9es et valid\u00e9es avant d’\u00eatre d\u00e9ploy\u00e9es sur le site r\u00e9el. Il existe de nombreux outils disponibles pour mettre en \u0153uvre le CI\/CD dans le d\u00e9veloppement de logiciels, nous utiliserons GitHub Actions<\/a> pour ce tutoriel.<\/p>\n

Qu’est-ce que GitHub Actions ?<\/h2>\n

GitHub Actions est un puissant outil d’automatisation fourni par GitHub. Il offre aux d\u00e9veloppeurs la possibilit\u00e9 d’automatiser diverses t\u00e2ches, processus et flux de travail au sein de leurs projets de d\u00e9veloppement logiciel. Il s’int\u00e8gre aux d\u00e9p\u00f4ts GitHub, ce qui le rend facile \u00e0 utiliser.<\/p>\n

Gr\u00e2ce aux actions GitHub et \u00e0 l’API Kinsta<\/a>, vous pouvez d\u00e9finir des flux de travail personnalis\u00e9s qui r\u00e9pondent aux exigences de votre projet. Vous pouvez mettre en place un pipeline CI qui teste votre application et d\u00e9clenche le d\u00e9ploiement sur Kinsta.<\/p>\n

D\u00e9marrer avec GitHub Actions<\/h2>\n

Les Actions GitHub fonctionnent sur le concept de flux de travail, qui sont des ensembles de t\u00e2ches automatis\u00e9es d\u00e9clench\u00e9es par des \u00e9v\u00e8nements sp\u00e9cifiques ou programm\u00e9es \u00e0 intervalles r\u00e9guliers. Ces \u00e9v\u00e8nements peuvent \u00eatre des pouss\u00e9es de code, des demandes d’extraction, la cr\u00e9ation d’une question, etc. Lorsque l’un de ces \u00e9v\u00e9nements se produit, GitHub Actions lance automatiquement un flux de travail associ\u00e9, en ex\u00e9cutant une s\u00e9rie d’\u00e9tapes pr\u00e9d\u00e9finies.<\/p>\n

Chaque \u00e9tape du flux de travail repr\u00e9sente une action particuli\u00e8re, telle que la construction du code, l’ex\u00e9cution de tests, le d\u00e9ploiement ou l’envoi de notifications. Cr\u00e9ons un flux de travail avec trois t\u00e2ches :<\/p>\n

    \n
  1. V\u00e9rifier la syntaxe avec ESLint<\/li>\n
  2. Ex\u00e9cuter les tests<\/li>\n
  3. Red\u00e9ployer votre application<\/li>\n<\/ol>\n

    \u00c9tape 1 : Configurer votre d\u00e9p\u00f4t GitHub<\/h3>\n

    Pour commencer \u00e0 utiliser les Actions GitHub, vous avez besoin d’un d\u00e9p\u00f4t GitHub.<\/p>\n

    Ici, nous utilisons ce d\u00e9p\u00f4t GitHub<\/a>, d\u00e9velopp\u00e9 pour le tutoriel Comment construire et d\u00e9ployer une application clone de ChatGPT avec React et OpenAI API<\/a>.<\/p>\n

    N’h\u00e9sitez pas \u00e0 utiliser le d\u00e9p\u00f4t vous-m\u00eame en naviguant jusqu’\u00e0 lui sur GitHub et en s\u00e9lectionnant : Utiliser ce mod\u00e8le<\/strong> > Cr\u00e9er un nouveau d\u00e9p\u00f4t<\/strong>.<\/p>\n

    Dans cette application React, des tests unitaires sont cr\u00e9\u00e9s pour tester chaque composant. ESLint est \u00e9galement utilis\u00e9 pour s’assurer que la syntaxe et le formatage du code sont parfaits. Le pipeline CI bloquera un d\u00e9ploiement si une demande d’extraction ou un code fusionn\u00e9 pouss\u00e9 vers le d\u00e9p\u00f4t \u00e9choue les tests du flux de travail.<\/p>\n

    \u00c9tape 2 : Cr\u00e9er un fichier de flux de travail<\/h3>\n

    D\u00e9finissez votre flux de travail en cr\u00e9ant un fichier YAML dans le r\u00e9pertoire .github\/workflows<\/strong> de votre d\u00e9p\u00f4t. Ce r\u00e9pertoire doit se trouver \u00e0 la racine de votre r\u00e9f\u00e9rentiel. La convention de nommage pour les fichiers de flux de travail est nom-du-flux-de-travail.yml<\/strong>.<\/p>\n

      \n
    1. Dans votre d\u00e9p\u00f4t, cr\u00e9ez un r\u00e9pertoire .github<\/strong>.<\/li>\n
    2. Dans le r\u00e9pertoire .github<\/strong>, cr\u00e9ez un nouveau r\u00e9pertoire appel\u00e9 workflows<\/strong>.<\/li>\n
    3. Dans le r\u00e9pertoire workflows, cr\u00e9ez un nouveau fichier avec un nom comme build-test-deploy.yml<\/strong>.<\/li>\n<\/ol>\n

      \u00c9tape 3 : \u00c9crire le flux de travail CI\/CD<\/h3>\n

      Maintenant que vous avez cr\u00e9\u00e9 votre fichier de flux de travail, d\u00e9finissez un flux de travail avec les \u00e9tapes n\u00e9cessaires pour v\u00e9rifier la syntaxe avec ESLint, ex\u00e9cuter les tests et d\u00e9ployer l’application.<\/p>\n

      Cr\u00e9er un \u00e9v\u00e9nement CI<\/h4>\n

      Lors de la cr\u00e9ation d’un pipeline CI, la premi\u00e8re \u00e9tape consiste \u00e0 donner un nom au flux de travail, puis \u00e0 d\u00e9finir l’\u00e9v\u00e9nement qui d\u00e9clenchera le flux de travail. Pour cet exemple, les deux \u00e9v\u00e9nements sont une pull request et un push vers la branche principale.<\/p>\n

      name: Build, Test, and Deploy\n\non:\n  push:\n    branches: \"main\"\n  pull_request:\n    branches: \"main\"<\/code><\/pre>\n
      Si vous souhaitez programmer des t\u00e2ches p\u00e9riodiques (CRON jobs) pour des t\u00e2ches sp\u00e9cifiques, vous pouvez les ajouter au flux de travail. Par exemple, vous pourriez vouloir ex\u00e9cuter certaines t\u00e2ches telles que des sauvegardes de bases de donn\u00e9es, des nettoyages de donn\u00e9es ou d’autres t\u00e2ches de maintenance p\u00e9riodiques.<\/p>\n
      Voici un exemple de la mani\u00e8re dont vous pouvez ajouter un travail CRON au flux de travail :<\/p>\n
      on:\n  # Existing event triggers for push and pull_request\n\n  # Add a schedule for CRON jobs\n  schedule:\n    - cron: \"0 0 * * *\"<\/code><\/pre>\n
      L’exemple ci-dessus d\u00e9clenchera le flux de travail tous les jours \u00e0 minuit (heure UTC) puisque le programme cron est d\u00e9fini sur 0 0 * * *<\/code>. Vous pouvez personnaliser le programme cron pour r\u00e9pondre \u00e0 vos besoins sp\u00e9cifiques.<\/p>\n
      Supposons que vous souhaitiez programmer le flux de travail CI\/CD pour qu’il s’ex\u00e9cute tous les lundis \u00e0 8 heures. Nous pouvons configurer une t\u00e2che CRON \u00e0 l’aide de l’\u00e9v\u00e8nement schedule<\/code>:<\/p>\n
      name: Build, Test, and Deploy\n\non:\n  push:\n    branches: \"main\"\n  pull_request:\n    branches: \"main\"\n\n  # Schedule the workflow to run every Monday at 8 a.m. (UTC time)\n  schedule:\n    - cron: \"0 8 * * 1\"\n\njobs:\n # Add jobs<\/code><\/pre>\n
      La syntaxe de planification utilis\u00e9e dans l’\u00e9v\u00e8nement schedule<\/code> pour les flux de travail GitHub Actions est bas\u00e9e sur la syntaxe UNIX cron. Elle vous permet de d\u00e9finir des heures ou des intervalles sp\u00e9cifiques pour l’ex\u00e9cution automatique de votre flux de travail. La syntaxe se compose de cinq champs qui repr\u00e9sentent diff\u00e9rents aspects de la planification. Chaque champ est s\u00e9par\u00e9 par un espace. Le format g\u00e9n\u00e9ral de la syntaxe de planification est le suivant :<\/p>\n
      * * * * *\n\u252c \u252c \u252c \u252c \u252c\n\u2502 \u2502 \u2502 \u2502 \u2502\n\u2502 \u2502 \u2502 \u2502 \u2514\u2500 Day of the week (0 - 7) (Sunday to Saturday, where both 0 and 7 represent Sunday)\n\u2502 \u2502 \u2502 \u2514\u2500\u2500\u2500 Month (1 - 12)\n\u2502 \u2502 \u2514\u2500\u2500\u2500\u2500\u2500 Day of the month (1 - 31)\n\u2502 \u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500 Hour (0 - 23)\n\u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500 Minute (0 - 59)<\/code><\/pre>\n
      D\u00e9composons maintenant chaque champ :<\/p>\n