Catégories
Plugin et site web

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

CI / CD (Continuous Integration and Continuous Deployment & Delivery) est une méthode moderne dans le cycle de développement logiciel qui réduit le processus répétitif de test et de déploiement de logiciel. Github Actions est l'un des services que nous pouvons utiliser pour réaliser CI / CD. Dans cet article, Aleem Isiaka explique comment déployer une application NodeJS de base sur Heroku, automatiser et planifier un déploiement à exécuter à certains intervalles de la journée et utiliser d'autres actions de la communauté Github Actions.

Avant l'invention du 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 garantir 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 le fonctionnement de l'intégration et de la livraison continues, nous nous concentrerons sur le déploiement d'un serveur d'API d'application de raccourcisseur d'URL sur Heroku à l'aide d'actions Github. L'application est un serveur NodeJS et prend en charge:

  • Raccourcir 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 dans le cadre de la réponse.
  • Visiter un lien raccourci en faisant une demande GET à /:code; le code est l'identifiant de code unique utilisé lors du raccourcissement de l'URL.
  • Analyse de surveillance en faisant une demande GET à /analysis/:code; les :code est l'identifiant de code unique utilisé lors du raccourcissement de 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 flux de travail extraira le code du référentiel d'applications, ajoutera l'URL distante Heroku git et déploiera enfin l'application sur Heroku.

À propos des actions Github

Github Actions est l'un des services proposés 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 du processus. 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 créer vos pratiques de développement logiciel. »

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

Composants des actions Github

Github Actions se compose de six composants principaux:

  1. Coureurs,
  2. Flux de travail,
  3. Événements,
  4. Travaux,
  5. Pas,
  6. Actions.
1. Coureurs

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, basés sur les machines virtuelles Standard_DS2_v2 de Microsoft Azure.

2. Flux de travail

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 .github/workflows dossier 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 .github/workflows dossier.

3. Evénements

Pour qu'un fichier de 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. Emplois

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 s'exécutent parallèlement les unes aux autres, et elles peuvent également être configurées pour s'exécuter en ordre séquentiel.

5. Étapes

Ce sont les éléments uniques qui composent un travail. Une étape regroupe les actions 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é telles que l'action de paiement.

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

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

Bouton pour créer un nouveau herokuapp
Bouton pour créer un nouveau herokuapp. (Grand aperçu)

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 le cloner localement en utilisant git clonegit@github.com:{your-username}/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éer un fichier nommé action.yml, ce fichier contiendra les instructions pour notre processus de déploiement sur Heroku via notre code sur Github. Nous exécuterons le code ci-dessous dans notre terminal pour réaliser ce processus.

$ cd path/to/repo
$ mkdir .github/workflows
$ touch .github/workflows/action.yml

Ensuite, nous ferons le .github/workflow/action.yml Le fichier a le contenu ci-dessous:

name: "Clone URL Shortener Github Actions"
 
on:
  push:
jobs:
  deploy-url-shortener:
    runs-on: ubuntu-latest
    steps:
      - name: "Checkout limistah:url-shortener"
        uses: actions/checkout@v1
        with:
          repository: "limistah/url-shortener"
          ref: "master"

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 événement sur la ligne 3 qui déclenchera le flux de travail une fois qu'un nouveau push est effectué vers le référentiel sur Github.

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

le steps La déclaration a quelques sous-éléments:

  • name champ qui distingue l'étape;
  • uses champ qui pourrait être utilisé pour importer des actions de la communauté;
  • with accepter les éléments qui servent d'arguments à l'action en cours.

Dans notre exemple de workflow, nous avons une étape que nous utilisons pour extraire un référentiel que nous souhaitons 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érifiez l'onglet Action de notre référentiel sur https://github.com/{your-username}/easy-urls/actions.

Tout le flux de travail pour le référentiel actuel
Tout le flux de travail pour le référentiel actuel. (Grand aperçu)

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

Tous les travaux du flux de travail actuel
Tous les travaux du workflow actuel. (Grand aperçu)

À 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 cliquons sur le deploy-url-shortener pour trouver les journaux sur le runner pour la poussée de validation que nous avons effectuée. Cliquez sur le nom d'un travail (deploy-url-shortener) pour lister toutes les étapes de la tâche, cliquez également sur le nom d'une tâche pour voir les détails de l'étape.

Détails des étapes de la tâche
Détails des étapes du travail. (Grand aperçu)

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

Authentifier 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'e-mail et un auth-token à un .netrc fichier 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 ouvrir une page sur votre navigateur par défaut pour vous connecter à Heroku en fournissant votre 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 de l'utilisateur actuel attaché au shell, utilisez cat ~/.netrc commande pour afficher le contenu du fichier, il doit suivre le format:

machine api.heroku.com
  login me@example.com
  password c4cd94da15ea0544802c2cfd5ec4ead324327430
machine git.heroku.com
  login me@example.com
  password 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 effectuer une action authentifiée à partir de n'importe quelle machine et même sur notre coureur d'action Github.

Utilisation de secrets pour stocker des informations confidentielles
Créer un nouveau secret
Créez un nouveau secret. (Grand aperçu)

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 le nom et la chaîne fournis par la sortie de heroku auth:token comme valeur et cliquez sur le Add secret bouton pour enregistrer 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 .netrc fichier pour chaque exécution de notre flux de travail. Nous utiliserons le cat pour créer le fichier et incorporer le secret en tant que variable d'environnement dans le contenu du fichier.

`cat >~/.netrc <

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

name: "Clone URL Shortener Github Actions"
 
on:
  push:
jobs:
  deploy-url-shortener:
    runs-on: ubuntu-latest
    steps:
      - name: "Checkout limistah:url-shortener"
        uses: actions/checkout@v1
        with:
          repository: "limistah/url-shortener"
          ref: "master"
      - name: "Create .netrc for Heroku Auth"
        shell: bash
        run: |
          `cat ≶~/.netrc <

le env domaine semble nouveau; c'est une méthode pour définir les variables d'environnement auxquelles une étape d'exécution aura accès. le env var peut être n'importe quelle chaîne valide et peut 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 auxquels nous accédons via le secrets variable 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 effectuer des actions authentifiées à l'aide de 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"
        run: |
          heroku git:remote --app aleem-urls

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

Déploiement de la branche principale

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:

- name: "Push to heroku"
        shell: "bash"
        run: |
          git push heroku HEAD:master

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

name: "Clone URL Shortener Github Actions"
 
on:
  push:
jobs:
  deploy-url-shortener:
    runs-on: ubuntu-latest
    steps:
      - name: "Checkout limistah:url-shortener"
        uses: actions/checkout@v1
        with:
          repository: "limistah/url-shortener"
          ref: "master"
      - name: "Create .netrc for Heroku Auth"
        shell: bash
        run: |
          `cat >~/.netrc <
Tester le déploiement

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

  • Sur la page du dépôt, cliquez sur le Actions languette;
  • Sur la page Actions, cliquez sur le nom de notre workflow (qui doit être Clone URL Shortener Github Actions);
  • Sur la page Workflow, cliquez sur le nom du travail (c.-à-d. deploy-url-shortener);
  • Sur la page Job, vous trouverez les workflows exécutés. Cliquez sur le nom de votre commit pour le déploiement afin de vérifier la sortie de l'action.
Déployer dans le journal principal de la branche
Déployer dans le journal principal de la branche. (Grand aperçu)

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

Tester la branche principale de déploiement
Tester la branche principale de déploiement. (Grand aperçu)

Visiter 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 le on élément clé et ajouter une propriété enfant, schedule. le schedule l'élément accepte un élément enfant cron qui doit être défini sur une valeur correspondant à la syntaxe cron POSIX.

La syntaxe cron POSIX suit le format:

┌───────────── minute (0 - 59)
│ ┌───────────── hour (0 - 23)
│ │ ┌───────────── day of the month (1 - 31)
│ │ │ ┌───────────── month (1 - 12 or JAN-DEC)
│ │ │ │ ┌───────────── day of the week (0 - 6 or 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:

0 La seconde exacte 0 pour le temps correspondant.
24 Le 24e heure à partir de l'heure de début.
* Correspond à tous les jours possibles du mois.
* Correspond tous les mois possibles dans un an.
* Matchs tous les jours de la semaine.

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 d'une unité de temps. Par exemple, nous pouvons avoir un cron à exécuter toutes les 2 minutes (le format serait */2 * * * *) ou faites-le exécuter tous les jours d'un mois (le format serait 0 0 */1 * *). le */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 flux de travail. Nous pouvons également créer et vérifier une syntaxe cron en utilisant https://crontab.guru.

Pour notre cas d'utilisation, nous souhaitons 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"
 
on:
  push:
  schedule:
    - cron: "*/10 * * * *"
jobs:
  deploy-url-shortener:
    runs-on: ubuntu-latest
    steps:
      - name: "Checkout limistah:url-shortener"
        uses: actions/checkout@v1
        with:
          # Repository name with owner. For example, actions/checkout
          # Default: ${{ github.repository }}
          repository: "limistah/url-shortener"
          ref: "master"
      - name: "Create .netrc for Heroku Auth"
        shell: bash
        run: |
          `cat >~/.netrc <

À ce stade, nous allons valider et pousser ce changement, puis nous diriger vers Github pour surveiller ce flux de travail en cliquant sur les 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 cliquez sur une action de la liste des actions pour le job en cours.

Déploiements planifiés toutes les 10 minutes à l'aide de Heroku Action
Déploiement programmé toutes les 10 minutes à l'aide de Heroku Action. (Grand aperçu)

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

Tirer parti des actions immédiatement 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 flux de travail avec seulement quelques changements. Les changements que nous pourrions avoir sont les suivants:

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

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

Nous pouvons éviter le scénario ci-dessus en réutilisant nos actions ou en tirant parti des 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.

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

- uses: akhileshns/heroku-deploy@v3.5.7 # This is the action we are importing
  with: # It accepts some arguments to work, we can pass the argument using `with`
    heroku_api_key: ${{secrets.HEROKU_AUTH_TOKEN}} # This is the same as the auth key we generated earlier
    heroku_app_name: "aleem-urls" #Must be unique in Heroku
    heroku_email: "me@email.com" # Email attached to the account

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 de flux de travail final ressemblerait à ceci:

name: "Clone URL Shortener Github Actions"
 
on:
  push:
  schedule:
    - cron: "*/30 * * * *"
jobs:
  deploy-url-shortener:
    runs-on: ubuntu-latest
    steps:
      - name: "Checkout limistah:url-shortener"
        uses: actions/checkout@v1
        with:
          # Repository name with owner. For example, actions/checkout
          # Default: ${{ github.repository }}
          repository: "limistah/url-shortener"
          ref: "master"
      - name: "Create .netrc for Heroku Auth"
        uses: akhileshns/heroku-deploy@v3.5.7 # This is the action we are importing
        with: # It accepts some arguments to work, we can pass the argument using `with`
          heroku_api_key: ${{secrets.HEROKU_AUTH_TOKEN}} # This is the same as the auth key we generated earlier
          heroku_app_name: "aleem-urls" #Must be unique in Heroku
          heroku_email: "aleemisiaka@gmail.com" # Email attached to the account

Nous allons valider ce nouveau changement, puis pousser, puis attendre l'heure prévue pour que notre cron vérifie le résultat de notre action.

Déploiements planifiés toutes les 10 minutes
Déploiement programmé toutes les 10 minutes. (Grand aperçu)

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.

Outre les nombreuses actions personnalisées disponibles de la communauté qui peuvent être trouvées sur le Github Actions Marketplace, nous pouvons également créer la nôtre en suivant le guide de Github sur la façon de créer des actions personnalisées pour chaque cas d'utilisation disponible.

Conclusion

Dans ce didacticiel, 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 de CI / CD, mais Github possède certaines 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 dans la communauté, ce qui réduit le temps nécessaire pour déployer un pipeline CI / CD pour une application.

Le déclencheur d'événement programmé 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éo de ruanyf qui envoie le bulletin météo de la journée directement à un e-mail à une heure précise de la journée. (Ceci est possible en utilisant un déclencheur d'événement planifié.)

Hormis la configuration 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.

Les références

Éditorial fracassant(ra, yk, il)

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *