Gérer l'intégration et la livraison continues avec les actions GitHub

Avant l'invention de CI / CD (Continuous Integration and Continuous Deployment & Delivery), le logiciel était généralement développé en écrivant le code à l'aide d'un ordinateur chaque fois qu'il était temps de passer le logiciel en production. Le site Web RedHat définit CI / CD comme «une méthode pour fournir fréquemment des applications aux clients en introduisant l'automatisation dans les étapes de développement d'applications. Les principaux concepts attribués à CI / CD sont l'intégration continue, la livraison continue et le déploiement continu. »

En d'autres termes, CI / CD est un processus qui remplace les méthodes traditionnelles / manuelles de création et de déploiement d'applications logicielles. Le processus CI / CD est automatisé et exécuté une fois qu'un déclencheur est atteint. Le déclencheur est principalement attaché à un nouveau commit git pour s'assurer que la dernière version du code d'un référentiel est construite et déployée avec un minimum d'effort pour le développeur.

Gestion de l'intégration et de la livraison continues avec les actions GitHub

Pour mieux comprendre comment continue travaux d'intégration et de livraison, nous nous concentrerons sur le déploiement d'une application de raccourcissement d'URL serveur API sur Heroku à l'aide d'actions Github. L'application est un serveur NodeJS et prend en charge:

• Raccourcissement d'une URL en faisant une requête POST à ​​ / shorten avec un corps de requête contenant le code pour identifier l'URL et un ] url comme URL vers laquelle rediriger. Si aucun code n'est envoyé, il génère simplement un code aléatoire et le renvoie comme partie de la réponse.
• Visite d'un lien raccourci en faisant une requête GET à /: code ; le code est l'identifiant de code unique utilisé lors du raccourcissement de l'URL.
• Analyse de surveillance en faisant une requête GET à / analysis /: code ; le : code est l'identifiant de code unique utilisé pour raccourcir l'URL.

Nous n'avons pas nécessairement à créer une nouvelle application car nous pouvons déployer un référentiel privé auquel notre compte Github a accès, mais nous pouvons également déployer un référentiel public. Le workflow va extraire le code du référentiel d'application, ajouter l'URL distante Heroku git et enfin déployer l'application sur Heroku.

À propos des actions Github

Github Actions est l'un des services offerts par Github Inc . Selon la note de publication :

«GitHub Actions est une API de cause à effet sur GitHub: orchestrez n'importe quel flux de travail, en fonction de n'importe quel événement, tandis que GitHub gère l'exécution, fournit des commentaires riches et sécurise chaque étape le long du chemin. Avec les actions GitHub, les flux de travail et les étapes ne sont que du code dans un référentiel, vous pouvez donc créer, partager, réutiliser et bifurquer vos pratiques de développement logiciel. »

Github Actions est l'une des nombreuses options qui pourraient être utilisées pour implémenter un logiciel continu déploiement et livraison (CI / CD) en veillant à ce qu’une nouvelle version d’un logiciel soit expédiée dès que possible dans la zone de production ou de test.

Composants des actions Github

Les actions Github se composent de six composants principaux:

1. ] Runners,
2. Workflows,
3. Events,
4. Jobs,
5. Steps,
6. Actions.

1. Runners

Ce sont des systèmes d'exploitation virtuels hébergés qui pourraient exécuter des commandes pour exécuter un processus de construction. Les coureurs d'actions Github peuvent être auto-hébergés ou choisis parmi l'un des coureurs gratuits mis à disposition par Github et basés sur les machines virtuelles Standard_DS2_v2 de Microsoft Azure.

2. Workflows

Ce sont des instructions présentées qui donnent l'application Github Action sur un coureur. Les instructions de workflow sont définies dans un fichier YAML et se trouvent à l'intérieur du dossier .github / workflows dans un référentiel git. Le nom d'un fichier de workflow n'a pas de corrélation avec l'intention du fichier, car Github analyse et exécute chaque fichier à l'intérieur du dossier .github / workflows .

3. Événements

Pour qu'un fichier Workflow soit traité et exécuté, un événement est requis. Un événement peut être une nouvelle fusion push ou pr, les actions Github peuvent écouter une liste d'événements déclenchés par un référentiel. À titre d'exemple de base, nous pourrions avoir un fichier de workflow qui
écoute l'événement push d'un référentiel pour traiter une nouvelle compilation de notre application.

4. Tâches

Une fois qu'un événement est déclenché, la série d'étapes exécutées pour ce workflow est une étape. Un travail peut répertorier une série d'étapes qui se déroulent parallèlement les unes aux autres, et elles peuvent également être configurées pour s'exécuter dans un ordre séquentiel.

5. Étapes

Ce sont les éléments uniques qui composent un travail. Une étape regroupe les actions qui sont effectuées sur un coureur.

6. Actions

Une action est un élément d'une étape et est essentiellement une commande. C'est une action qui est exécutée sur le coureur et, en tant que telle, est au cœur des actions Github. Nous pouvons avoir notre propre action personnalisée telle que npm install ou tirer parti des actions existantes créées par la communauté, comme l'action d'extraction .

Configuration d'un flux de travail pour une application Node.js

Dans cette section, nous déploierons une application NodeJS sur un serveur distant. Dans ce cas, nous utiliserons Heroku comme serveur de déploiement, nous devons donc créer un compte puis une application.

Inscription et création d'un compte sur Heroku

Inscrivez-vous pour un compte Heroku à partir de ici et connectez-vous à votre compte. Depuis le tableau de bord, cliquez sur le nouveau bouton puis sur créez une nouvelle application . Entrez un nom unique pour l'application et cliquez sur le bouton Créer.

Connectez-vous à votre compte Github ou créez-en un nouveau si vous n'en avez pas, puis créez un nouveau dépôt Github pour notre application nommée aleem- urls et clonez-le localement en utilisant git clone git@github.com : {votre-nom d'utilisateur} /aleem-urls.git .

Depuis la racine de notre application , créez un dossier nommé .github / workflows qui contiendra tous les workflows d'action GitHub dans ce dossier créez un fichier nommé action.yml ce fichier contiendra les instructions pour notre processus de déploiement à Heroku via notre code sur Github. Nous exécuterons le code ci-dessous dans notre terminal pour réaliser ce processus.

 $ cd chemin / vers / repo
$ mkdir .github / flux de travail
$ touch .github / workflows / action.yml

Ensuite, nous allons faire en sorte que le fichier .github / workflow / action.yml ait le contenu ci-dessous:

 nom: "Clone URL Shortener Github Actions"
 
sur:
  pousser:
travaux:
  deploy-url-shortener:
    run-on: ubuntu-latest
    pas:
      - nom: "Checkout limistah: url-shortener"
        utilise: actions / checkout @ v1
        avec:
          dépôt: "limistah / url-shortener"
          ref: "maître"

L'extrait YAML ci-dessus est un workflow d'action Github typique, et dans ce workflow, nous avons défini le nom du workflow sur la première ligne comme "Clone URL Shortener Github Actions" et écoutons également un push sur la ligne 3 qui déclenchera le flux de travail une fois qu'une nouvelle poussée est effectuée vers le référentiel sur Github.

Le point central d'un flux de travail Github Action est étapes – cela pourrait être trouvé sous la spécification jobs . Le flux de travail ci-dessus spécifie un travail deploy-url-shortener et à l'intérieur de celui-ci, nous avons défini où nous voulons que le travail s'exécute en utilisant le champ runs-on et avons les commandes pour être exécutée à l'intérieur des champs steps .

La déclaration steps comporte quelques sous-éléments:

• name qui distingue l'étape; [19659007] utilise le champ qui pourrait être utilisé pour importer des actions de la communauté;
• avec accepte les éléments qui servent d'arguments à l'action en cours.

Dans notre exemple de workflow, nous ont une étape que nous utilisons pour extraire un référentiel que nous voulons déployer sur Heroku. Nous aurions pu extraire le code dans notre nouveau référentiel puisque l'action Github peut le faire pour nous, nous devrions en tirer parti. Comme nous ne forçons pas le référentiel ou n'utilisons pas notre propre référentiel personnel, nous sommes limités aux fonctionnalités fournies par le référentiel, nous ne pouvons pas apporter de mises à jour ou de correctifs à notre déploiement sauf que l'auteur du référentiel effectue la mise à jour.

Pour tester le workflow, nous validerons le changement que nous avons (un nouveau fichier dans le .github / workflows / action.yml ), et vérifierons l'onglet Action de notre référentiel sur https: // github .com / {votre-nom d'utilisateur} / easy-urls / actions .

Sur la page Actions du référentiel, nous retrouverons tous les workflows que nous avons dedans. Nous pouvons afficher les détails du workflow en cliquant sur le nom du workflow.

À droite sur une page de détails de flux de travail, nous trouverons les travaux répertoriés pour le flux de travail particulier. Nous allons cliquer sur le deploy-url-shortener pour trouver les logs sur le runner pour la poussée de commit que nous avons faite. Cliquez sur le nom d'un job ( deploy-url-shortener ) pour lister toutes les étapes du job, cliquez également sur le nom d'un job pour voir les détails de l'étape.

En regardant de plus près et en inspectant l'étape Checkout limistah: url-shortener le coureur actuel a accès au code de raccourcissement d'url sur lequel nous voulons déployer Heroku.

Authentification de Heroku

Pour déployer sur Heroku, nous devons authentifier Heroku sur le runner pour notre workflow de déploiement. Nous pouvons utiliser la méthode d'authentification Auth Token par Heroku qui stocke l'email et un auth-token dans un fichier .netrc dans le répertoire personnel de l'utilisateur actuel.

Tout d'abord, assurez-vous que la CLI Heroku est installée, ouvrez un shell / terminal / cmd et utilisez la commande heroku login . Cela devrait faire apparaître une page sur votre navigateur par défaut pour vous connecter à Heroku en fournissant votre adresse e-mail et votre mot de passe.

Une fois que vous êtes connecté, un fichier .netrc devrait avoir été créé dans le répertoire personnel du utilisateur actuel attaché au shell, utilisez la commande cat ~ / .netrc pour afficher le contenu du fichier, il doit suivre le format:

 machine api.heroku.com
  connectez-vous me@example.com
  mot de passe c4cd94da15ea0544802c2cfd5ec4ead324327430
machine git.heroku.com
  connectez-vous me@example.com
  mot de passe c4cd94da15ea0544802c2cfd5ec4ead324327430

Maintenant, nous pouvons obtenir le jeton d'authentification en utilisant heroku auth: token qui devrait afficher la même chaîne que le mot de passe dans le fichier .netrc c4cd94da15ea0544802c2cfd5ec4ead324327430 .

Avec ce jeton, nous pouvons faire des actions authentifiées à partir de n'importe quelle machine et même sur notre coureur d'action Github.

Utilisation de secrets pour stocker des informations confidentielles

Nous pouvons stocker des secrets et des informations confidentielles sans les exposer au public dans notre référentiel en utilisant Encrypted Secrets nous le ferons avec notre jeton d'authentification Heroku.

Depuis la page du référentiel, cliquez sur Paramètres, puis Secrets dans le menu-liste de gauche, enfin, cliquez sur Ajouter un nouveau secret. La page Nouveau secret contient un formulaire avec des entrées Nom et Valeur, entrez HEROKU_AUTH_TOKEN comme nom et la chaîne fournie à partir de la sortie de heroku auth: token comme valeur et cliquez sur le Bouton Ajouter un secret pour sauvegarder le secret.
Accéder aux secrets

Par défaut, les secrets ne sont pas mis à disposition des workflows et des jobs, pour avoir accès aux secrets, nous devons les demander explicitement aux étapes nécessaires.

Dans notre cas, nous déployons sur Heroku, nous devons créer un fichier .netrc pour chaque exécution de notre workflow. Nous utiliserons la commande cat pour créer le fichier et intégrer le secret comme variable d'environnement dans le contenu du fichier.

 `cat> ~ / .netrc << EOF
          machine api.heroku.com
              login $ EMAIL
              mot de passe $ HEROKU_AUTH_TOKEN
          machine git.heroku.com
              login $ EMAIL
              mot de passe $ HEROKU_AUTH_TOKEN
          EOF`

Nous pouvons mettre à jour notre action.yml pour ressembler à ceci:

 name: "Clone URL Shortener Github Actions"
 
sur:
  pousser:
travaux:
  deploy-url-shortener:
    run-on: ubuntu-latest
    pas:
      - nom: "Checkout limistah: url-shortener"
        utilise: actions / checkout @ v1
        avec:
          référentiel: "limistah / url-shortener"
          ref: "maître"
      - nom: "Créer .netrc pour Heroku Auth"
        coquille: bash
        exécuter: |
          `chat & lg; ~ / .netrc << EOF
          machine api.heroku.com
              login $ EMAIL
              mot de passe $ HEROKU_AUTH_TOKEN
          machine git.heroku.com
              login $ EMAIL
              mot de passe $ HEROKU_AUTH_TOKEN
          EOF`
        env:
          COURRIEL: me@gmail.com
          HEROKU_AUTH_TOKEN: $ {{secrets.HEROKU_AUTH_TOKEN}}

Le champ env semble nouveau; c'est une méthode pour définir les variables d'environnement auxquelles une étape d'exécution aura accès. La variable env peut être n'importe quelle chaîne valide, et pourrait provenir des secrets stockés dans les paramètres d'un référentiel.

Nous définissons le HEROKU_AUTH_TOKEN pour utiliser les secrets, ce que nous sommes accéder via la variable secrets fournie par Github Actions pour accéder à tout secret spécifié pour le référentiel dans ses paramètres secrets.

Ajouter Heroku à la télécommande

Maintenant que nous pouvons authentifier un coureur, nous pouvons transporter sur les actions authentifiées en utilisant Heroku CLI. Nous ajouterons l'URL distante Heroku git au référentiel de raccourcissement d'URL que nous avions extrait dans l'action d'extraction via la commande heroku git: remote --app app-name pour l'application particulière que nous avons créée.

Nous ajouterons nos étapes pour inclure la configuration ci-dessous:

 - name: "Add remote"
        shell: "bash"
        exécuter: |
          heroku git: remote --app aleem-urls

Remarque : La valeur de aleem-urls devrait être le nom unique de l'application que nous avons créée sur Heroku.

Deploying The Master Branch

Enfin, nous pouvons ajouter une étape pour pousser la branche principale vers Heroku pour le déploiement, nous ajouterons nos étapes de flux de travail pour inclure:

 - nom: "Push to heroku"
        shell: "bash"
        exécuter: |
          git push heroku HEAD: maître

La configuration finale pour le déploiement Heroku devrait ressembler à ce qui suit:

 name: "Clone URL Shortener Github Actions"
 
sur:
  pousser:
travaux:
  deploy-url-shortener:
    run-on: ubuntu-latest
    pas:
      - nom: "Checkout limistah: url-shortener"
        utilise: actions / checkout @ v1
        avec:
          dépôt: "limistah / url-shortener"
          ref: "maître"
      - nom: "Créer .netrc pour Heroku Auth"
        coquille: bash
        exécuter: |
          `chat> ~ / .netrc << EOF
          machine api.heroku.com
              login $ EMAIL
              mot de passe $ HEROKU_AUTH_TOKEN
          machine git.heroku.com
              login $ EMAIL
              mot de passe $ HEROKU_AUTH_TOKEN
          EOF`
        env:
          COURRIEL: aleemisiaka@gmail.com
          HEROKU_AUTH_TOKEN: $ {{secrets.HEROKU_AUTH_TOKEN}}
      - nom: "Ajouter une télécommande"
        shell: "bash"
        exécuter: |
          heroku git: remote --app aleem-urls
      - nom: "Push to heroku"
        shell: "bash"
        exécuter: |
          git push heroku HEAD: maître

Test du déploiement

Afin de vérifier si notre flux de travail est correct, nous devons valider les changements et pousser le nouveau commit dans le référentiel. Nous pouvons visualiser les processus qui ont été effectués avec les étapes suivantes:

• Sur la page du dépôt, cliquez sur l'onglet Actions ;
• Sur la page Actions, cliquez sur le nom de notre workflow (qui devrait be Clone URL Shortener Github Actions );
• Sur la page Workflow, cliquez sur le nom du job (par exemple deploy-url-shortener );
• On the Job page, vous trouverez les workflows exécutés. Cliquez sur le nom de votre validation pour le déploiement afin de vérifier le résultat de l'action.

Si l'un des processus a échoué, nous pouvons cliquer sur le nom de l'étape afin d'inspecter les logs. Nous sommes plus intéressés par l'étape Push to heroku puisque c'est celle qui nous informe si le déploiement a réussi et nous fournit une URL pour accéder à l'application.

Grand aperçu )

La ​​visite de l'URL https://aleem-urls.herokuapp.com/ devrait charger une page d'état de l'application de raccourcissement d'URL. Voilà!

Planification des actions

Github Action peut également servir de cron, qui exécute des workflows à une heure précise de la journée. Nous pouvons utiliser cette fonctionnalité pour automatiser le déploiement de notre application à un certain moment de la journée, nous pouvons y parvenir en ajoutant quelques instructions à notre fichier YAML de flux de travail.

À partir de la dernière version complète que nous avions, nous devons mettre à jour l'élément clé sur et ajouter une propriété enfant, annexe . L'élément schedule accepte un élément enfant cron qui doit être défini sur une valeur correspondant à la syntaxe POSIX cron.

La syntaxe POSIX cron suit le format:

 ┌─ ──────────── minute (0 - 59)
│ ┌───────────── Heure (0-23)
│ │ ┌────────────── jour du mois (1 - 31)
│ │ │ ┌────────────── mois (1 - 12 ou JAN-DEC)
│ │ │ │ ┌────────────── jour de la semaine (0 - 6 ou SUN-SAT)
│ │ │ │ │
│ │ │ │ │
│ │ │ │ │
* * * * *

Nous pouvons également utiliser * à la place de la valeur numérique pour chaque unité si nous voulons que cette section corresponde à toutes les valeurs possibles. Par exemple, nous pouvons définir un cron pour qu'il s'exécute tous les jours en utilisant 0 24 * * * nous pouvons donc traduire le format de l'heure en:

Une autre fonctionnalité intéressante que nous pouvons obtenir avec le format de temps cron POSIX est que nous pouvons demander à un cron de fonctionner à une fraction de une unité de temps. Par exemple, nous pouvons faire exécuter un cron toutes les 2 minutes (le format serait * / 2 * * * * ) ou le faire exécuter tous les jours d'un mois (le format serait 0 0 * / 1 * * ). * / fractional-unit permet de créer des tâches cron répétées qui s'exécutent lorsqu'une fraction de l'unité de temps spécifiée correspond. Github a une excellente documentation sur les formats possibles que nous pouvons avoir en utilisant cron pour planifier nos workflows. Nous pouvons également créer et vérifier une syntaxe cron en utilisant https://crontab.guru .

Pour notre cas d'utilisation, nous voulons déployer notre application toutes les 10 minutes. Notre format d'heure cron serait alors * / 10 * * * * donc le fichier de workflow final devrait ressembler à ceci:

 name: "Clone URL Shortener Github Actions"
 
sur:
  pousser:
  programme:
    - cron: "* / 10 * * * *"
travaux:
  deploy-url-shortener:
    run-on: ubuntu-latest
    pas:
      - nom: "Checkout limistah: url-shortener"
        utilise: actions / checkout @ v1
        avec:
          # Nom du référentiel avec le propriétaire. Par exemple, actions / paiement
          # Par défaut: $ {{github.repository}}
          dépôt: "limistah / url-shortener"
          ref: "maître"
      - nom: "Créer .netrc pour Heroku Auth"
        coquille: bash
        exécuter: |
          `chat> ~ / .netrc << EOF
          machine api.heroku.com
              login $ EMAIL
              mot de passe $ HEROKU_AUTH_TOKEN
          machine git.heroku.com
              login $ EMAIL
              mot de passe $ HEROKU_AUTH_TOKEN
          EOF`
        env:
          COURRIEL: aleemisiaka@gmail.com
          HEROKU_AUTH_TOKEN: $ {{secrets.HEROKU_AUTH_TOKEN}}
      - nom: "Ajouter une télécommande"
        shell: "bash"
        exécuter: |
          heroku git: remote --app aleem-urls
      - nom: "Push to heroku"
        shell: "bash"
        exécuter: |
          git push heroku HEAD: maître

À ce stade, nous allons valider et pousser cette modification, puis nous dirigerons vers Github pour surveiller ce flux de travail en cliquant sur Actions, puis en cliquant sur le nom du flux de travail (Clone URL Shortener Github Actions), puis sur le nom du travail que nous voulons inspecter ( deploy-url-shortener ) et enfin cliquer sur une action de la liste des actions pour le travail en cours.

Nous pouvons surveiller le résultat de ce processus planifié à partir du tableau de bord Github Action où nous verrons les journaux de notre action planifiée s'exécuter à l'heure spécifiée que nous avions définie en utilisant la syntaxe de l'heure POSIX

Tirer parti des actions facilement disponibles

Dans la dernière section de cet article, nous avons déployé une application NodeJS sur Heroku bien que nous puissions avoir d'autres applications suivant ce processus de workflow avec juste quelques changements. Les changements que nous pourrions avoir sont les suivants:

• Le nom de l'application sur Heroku;
• Le référentiel où se trouve le code à déployer.

La copie du fichier de workflow sur de nombreux référentiels pour le déploiement pourrait devenir répétitive, aussi , le workflow original que nous dupliquerions pourrait avoir une erreur, nous obligeant à copier des erreurs sur nos workflows et déploiements.

Nous pouvons éviter le scénario ci-dessus en réutilisant nos actions ou en exploitant les actions créées par la communauté. En fait, nous avions utilisé une action développée par la communauté dans notre fichier de workflow nommé checkout .

Nous pouvons le faire pour déployer notre application sur Heroku en utilisant une action développée par la communauté nommée Deploy to Heroku [19659138].

Pour importer cette action, nous devons mettre à jour la section étapes de notre travail de déploiement pour avoir le code ci-dessous:

 - uses: akhileshns/heroku-deploy@v3.5.7 # C'est l'action que nous sommes importation
  with: # Il accepte certains arguments pour fonctionner, nous pouvons passer l'argument en utilisant `with`
    heroku_api_key: $ {{secrets.HEROKU_AUTH_TOKEN}} # C'est la même que la clé d'authentification que nous avons générée précédemment
    heroku_app_name: "aleem-urls" #Doit être unique dans Heroku
    heroku_email: "me@email.com" # Email joint au compte

Nous ne voulons pas de doubles déploiements; nous préférerions mettre à jour l'action de déploiement de notre workflow avec cette nouvelle version en utilisant une action réutilisable.

Le fichier final du workflow ressemblerait à ceci:

 name: "Clone URL Shortener Github Actions"
 
sur:
  pousser:
  programme:
    - cron: "* / 30 * * * *"
travaux:
  deploy-url-shortener:
    run-on: ubuntu-latest
    pas:
      - nom: "Checkout limistah: url-shortener"
        utilise: actions / checkout @ v1
        avec:
          # Nom du référentiel avec le propriétaire. Par exemple, actions / paiement
          # Par défaut: $ {{github.repository}}
          référentiel: "limistah / url-shortener"
          ref: "maître"
      - nom: "Créer .netrc pour Heroku Auth"
        utilise: akhileshns/heroku-deploy@v3.5.7 # C'est l'action que nous importons
        with: # Il accepte certains arguments pour fonctionner, nous pouvons passer l'argument en utilisant `with`
          heroku_api_key: $ {{secrets.HEROKU_AUTH_TOKEN}} # C'est la même que la clé d'authentification que nous avons générée précédemment
          heroku_app_name: "aleem-urls" #Doit être unique dans Heroku
          heroku_email: "aleemisiaka@gmail.com" # Email attaché au compte

Nous validerons ce nouveau changement, puis pousserons, puis attendrons l'heure prévue pour que notre cron vérifie le résultat de notre action.

L'utilisation d'actions réutilisables ne rend pas seulement notre flux de travail plus lisible; il garantit également qu'il fonctionne de manière prévisible et nous n'avons que quelques endroits pour rechercher des erreurs dans tous les cas, nous rencontrons des résultats inattendus.

Mis à part les nombreuses actions personnalisées disponibles de la communauté qui pourraient être trouvées sur le Github Actions Marketplace, nous pouvons également créer la nôtre en suivant le guide de Github sur comment créer des actions personnalisées pour chaque cas d'utilisation disponible.

Conclusion

Dans ce tutoriel, nous avons exploré CI / CD et utilisé Github Actions comme fournisseur CI / CD pour déployer une application NodeJS à partir d'un référentiel Github vers Heroku.

Nous aurions pu réaliser ce même processus avec d'autres fournisseurs CI / CD mais Github a quelques fonctionnalités qui en font un excellent choix pour les développeurs. En plus de faire partie des outils de développement logiciel, Github Actions a été créé pour suivre l'idée open-source de Github en garantissant que les actions réutilisables peuvent être partagées au sein de la communauté, ce qui réduit à son tour le temps nécessaire pour déployer un pipeline CI / CD. pour une application.

Le déclencheur d'événement planifié est un autre avantage qui fait de Github Action un bon choix, une utilisation unique de celui-ci est un référentiel météorologique par ruanyf qui envoie le bulletin météo de la journée directement dans un e-mail à une heure précise de la journée. (Ceci est possible en utilisant un déclencheur d'événement planifié.)

Outre que la configuration est très simple via un fichier YAML structuré, Github Action est une excellente option CI / CD compte tenu du niveau de flexibilité qu'il offre à ses utilisateurs.

Références

(ra, yk, il)