Précédent

Suivant

Comment les actions GitHub automatisent les tâches de développement ?

Effectué

Nous allons ici présenter GitHub Actions et les workflows. Vous allez découvrir les types d’actions que vous pouvez utiliser et où les trouver. Vous allez également découvrir des exemples de ces types d’actions et leur rôle dans le workflow.

GitHub réduit le temps de l’idée au déploiement

GitHub est conçu pour aider les équipes de développeurs et d’ingénieurs DevOps à créer et à déployer rapidement des applications. Il existe de nombreuses fonctionnalités dans GitHub qui permettent cela, mais elles appartiennent généralement à l’une des deux catégories suivantes :

• Communication : prenez en compte toutes les façons dont GitHub permet à une équipe de développeurs de communiquer facilement sur le projet de développement logiciel : les révisions de code dans les requêtes de demande de tirage (pull request), les problèmes GitHub, les tableaux de projets, les wikis, les notifications, etc.
• Automatisation : la fonctionnalité GitHub Actions permet à votre équipe d’automatiser des flux de travail à chaque étape du processus de développement logiciel, de l’intégration au déploiement en passant par la livraison. Elle vous permet même d’automatiser l’ajout d’étiquettes à des demandes de tirage, ainsi que la vérification de problèmes et demandes de tirage obsolètes.

Quand elles sont combinées, ces fonctionnalités permettent à des milliers d’équipes de développement de réduire efficacement le temps nécessaire de l’idée initiale au déploiement.

Utiliser l’automatisation de workflow pour réduire le temps de développement

Nous allons nous concentrer sur l’automatisation dans ce module. Nous allons donc prendre un moment pour comprendre comment les équipes peuvent utiliser l’automatisation pour réduire le temps nécessaire à l’exécution d’un workflow de développement et de déploiement classique.

Examinez toutes les tâches qui doivent se produire après écriture du code, mais avant que vous puissiez utiliser le code de façon fiable pour son rôle prévu. En fonction des objectifs de votre organisation, vous devrez probablement effectuer une ou plusieurs des tâches suivantes :

• vérifier que le code réussit tous les tests unitaires
• Effectuer des vérifications de la conformité et de la qualité du code pour s’assurer que le code source répond aux normes de l’organisation
• vérifier le code et ses dépendances pour les problèmes de sécurité connus
• générer le code intégrant une nouvelle source à partir de plusieurs contributeurs (potentiellement)
• vérifier que le logiciel réussit les tests d’intégration
• Version de la nouvelle build
• Fournir les nouveaux fichiers binaires à l’emplacement approprié du système de fichiers
• Déployer les nouveaux fichiers binaires sur un ou plusieurs serveurs
• Si l’une de ces tâches ne réussit pas, signalez le problème à l’équipe ou à la personne appropriée pour sa résolution

Le défi consiste à effectuer ces tâches de façon fiable, cohérente et durable. Il s’agit d’une tâche idéale pour l’automatisation des workflow. Si vous utilisez déjà GitHub, vous souhaiterez probablement configurer l’automatisation de votre workflow à l’aide de GitHub Actions.

Qu’est-ce qu’une action GitHub ?

La fonctionnalité GitHub Actions est un ensemble de scripts empaquetés qui permet d’automatiser les tâches d’un workflow de développement logiciel dans GitHub. Vous pouvez configurer GitHub Actions pour déclencher des workflows complexes qui répondent aux besoins de votre organisation chaque fois que les développeurs vérifient le nouveau code source dans une branche spécifique, à intervalles réguliers ou manuellement. Le résultat est un workflow automatisé fiable et viable, ce qui réduit considérablement le temps de développement.

Où pouvez-vous trouver GitHub Actions ?

GitHub Actions sont des scripts qui adhèrent à un format de données yml. Chaque référentiel possède un onglet Actions qui fournit un moyen simple et rapide de commencer à configurer votre premier script. Si vous voyez un workflow que vous pensez être un excellent point de départ, sélectionnez juste le bouton Configurer pour ajouter le script et commencer à modifier la source yml.

Toutefois, au-delà de GitHub Actions proposé sous l’onglet Actions, vous pouvez :

• Rechercher GitHub Actions dans la Place de marché GitHub. La Place de marché GitHub vous permet de découvrir et d’acheter des outils qui étendent votre workflow.
• Rechercher des projets open source. Par exemple, l’organisation GitHub Actions comprend de nombreux dépôts open source populaires contenant les actions GitHub que vous pouvez utiliser.
• Écrire votre propre GitHub Actions à partir de zéro. En outre, si vous le souhaitez, vous pouvez les rendre open source ou même les publier sur la Place de marché GitHub.

Utiliser des actions GitHub open source

De nombreuses actions GitHub sont open source et disponibles pour toute personne souhaitant les utiliser. Toutefois, comme avec n’importe quel logiciel open source, vous devez soigneusement les vérifier avant de les utiliser dans votre projet. À l’instar des normes de la communauté recommandées avec des logiciels open source, comme l’inclusion d’un fichier Lisez-moi, d’un code de conduite, d’un fichier de contribution et de l’émission de modèles, pour ne citer que quelques exemples, vous pouvez suivre les suggestions ci-dessous lors de l’utilisation de GitHub Actions :

• Examinez le fichier action.yml de l’action pour les entrées et les sorties, et assurez-vous que le code fait ce qu’il dit.
• Vérifiez si l’action se trouve sur la Place de marché GitHub. C’est une bonne vérification à faire, même si une action n’a pas besoin d’être sur la Place de marché GitHub pour être valide.
• Vérifiez si l’action est vérifiée sur la Place de marché GitHub. Cela signifie que GitHub a approuvé l’utilisation de cette action. Toutefois, vous devez toujours l’examiner avant de l’utiliser.
• Incluez la version de l’action que vous utilisez en spécifiant une référence Git, un hachage SHA ou une étiquette.

Types d’actions GitHub

Il existe trois types d’actions GitHub : les actions de conteneur, les actions JavaScript et les actions composites.

Avec les actions de conteneur, l’environnement fait partie du code de l’action. Ces actions peuvent uniquement être exécutées dans un environnement Linux que GitHub héberge. Les actions de conteneur prennent en charge un grand nombre de langages.

Les actions JavaScript n’inclut pas l’environnement dans code. Vous devez spécifier l’environnement qui doit exécuter ces actions. Vous pouvez exécuter ces actions sur une machine virtuelle locale ou située dans le cloud. Les actions JavaScript prennent en charge les environnements Linux, macOS et Windows.

Les actions composites vous permettent de combiner plusieurs étapes de workflow dans une même action. Par exemple, vous pouvez utiliser cette fonctionnalité pour regrouper plusieurs commandes d’exécution dans une action, puis utiliser un workflow pour exécuter les commandes groupées en une seule étape à l’aide de cette action.

L’anatomie d’une action GitHub

Voici un exemple d’action qui effectue une opération « git checkout » sur un dépôt. Cette action, actions/checkout@v1, fait partie d’une étape dans un workflow. Cette étape génère également le code Node.js qui a été extrait. Nous allons aborder les workflows, les travaux et les étapes dans la section suivante.

steps:
  - uses: actions/checkout@v1
  - name: npm install and build webpack
    run: |
      npm install
      npm run build

Supposons que vous souhaitiez utiliser une action de conteneur pour exécuter du code conteneurisé. Votre action peut ressembler à ceci :

name: "Hello Actions"
description: "Greet someone"
author: "octocat@github.com"

inputs:
    MY_NAME:
      description: "Who to greet"
      required: true
      default: "World"

runs:
    uses: "docker"
    image: "Dockerfile"

branding:
    icon: "mic"
    color: "purple"

Remarquez la section inputs. Ici, vous obtenez la valeur d’une variable appelée MY_NAME. Cette variable sera définie dans le workflow qui exécute cette action.

Dans la section runs, notez que vous devez spécifier docker dans l’attribut uses. Dans ce cas, vous devez fournir le chemin du fichier image Docker. Ici, ce fichier se nomme Dockerfile. Nous n’aborderons pas ici les spécificités de Docker. Toutefois, si vous souhaitez obtenir plus d’informations, consultez le module Introduction aux conteneurs Docker.

La dernière section intitulée Personnalisation explique comment personnaliser votre action dans GitHub Marketplace, si vous décidez de l’y publier.

Pour obtenir la liste complète des métadonnées d’action, consultez Metadata syntax for GitHub Actions.

Qu’est-ce qu’un workflow GitHub Actions ?

Un workflow GitHub Actions est un processus que vous configurez dans votre dépôt afin d’automatiser les tâches du cycle de vie du développement logiciel, notamment les actions GitHub. Avec un workflow, vous pouvez générer, tester, empaqueter, publier et déployer n’importe quel projet sur GitHub.

Pour créer un workflow, vous devez ajouter des actions à un fichier .yml dans le répertoire .github/workflows de votre dépôt GitHub.

Dans l’exercice qui suit, votre fichier de workflow main.yml aura l’apparence suivante :

name: A workflow for my Hello World file
on: push
jobs:
  build:
    name: Hello world action
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v1
    - uses: ./action-a
      with:
        MY_NAME: "Mona"

Vous voyez l’attribut on:. Il s’agit d’un déclencheur qui permet de spécifier à quel moment le workflow doit s’exécuter. Ici, l’exécution est déclenchée lorsqu’un événement de poussée se produit vers votre dépôt. Vous pouvez spécifier des événements uniques comme on: push, un tableau d’événements comme on: [push, pull_request], ou un mappage de configuration d’événement qui planifie un workflow ou restreint l’exécution d’un workflow à certains fichiers, étiquettes ou modifications de branche. Voici à quoi doit ressembler le mappage :

on:
  # Trigger the workflow on push or pull request,
  # but only for the main branch
  push:
    branches:
      - main
  pull_request:
    branches:
      - main
  # Also trigger on page_build, as well as release created events
  page_build:
  release:
    types: # This configuration does not affect the page_build event above
      - created

Un événement se déclenche pour tous les types d’activités, sauf si vous spécifiez un ou plusieurs types. Pour obtenir la liste complète des événements et leurs types d’activité, consultez Événements qui déclenchent des workflows dans la documentation de GitHub.

Un workflow doit comprendre au moins un travail. Un travail est une section du workflow associée à un exécuteur. Un exécuteur peut être hébergé dans GitHub ou être auto-hébergé, et le travail peut s’exécuter sur un ordinateur ou dans un conteneur. Vous allez spécifier l’exécuteur avec l’attribut runs-on:. Ici, vous indiquez au workflow qu’il doit exécuter ce travail sur ubuntu-latest.

Chaque travail comporte des étapes à effectuer. Dans notre exemple, l’étape utilise l’action actions/checkout@v1 pour extraire le dépôt. Ce qui est intéressant, c’est la valeur uses: ./action-a, qui est le chemin de l’action de conteneur que vous générez dans un fichier action.yml. Nous avons examiné le contenu d’un fichier action.yml dans la section Qu’est-ce que GitHub Actions ?

La dernière partie de ce fichier de workflow définit la valeur de variable MY_NAME pour ce workflow. N’oubliez pas que l’action de conteneur a pris une entrée appelée MY_NAME.

Pour plus d’informations sur la syntaxe des workflows, consultez Workflow syntax for GitHub Actions.

Exécuteurs hébergés sur GitHub et auto-hébergés

Nous avons brièvement mentionné les exécuteurs comme étant associés à un travail. Un exécuteur est simplement un serveur sur lequel l’application d’exécuteur GitHub Actions est installée. Dans l’exemple de workflow précédent, il existait un attribut runs-on: ubuntu-latest dans le bloc de travaux qui indiquait au workflow que le travail allait s’exécuter en utilisant l’exécuteur hébergé par GitHub qui s’exécute dans l’environnement ubuntu-latest.

En ce qui concerne les exécuteurs, il existe deux options parmi lesquelles choisir : Exécuteurs hébergés par GitHub ou auto-hébergés. Si vous utilisez un exécuteur hébergé par GitHub, chaque travail s’exécute dans une nouvelle instance d’environnement virtuel qui est spécifié par le type d’exécuteur hébergé sur GitHub que vous définissez, runs-on: {operating system-version}. Avec les exécuteurs auto-hébergés, vous devez appliquer l’étiquette Auto-hébergé, son système d’exploitation et l’architecture système. Par exemple, un exécuteur auto-hébergé avec un système d’exploitation Linux et une architecture ARM32 ressemble à ce qui suit : runs-on: [self-hosted, linux, ARM32].

Chaque type d’exécuteur présente ses avantages, mais les exécuteurs hébergés sur GitHub offrent un moyen plus rapide et plus simple d’exécuter vos workflows, bien qu’avec des options limitées. Les exécuteurs auto-hébergés sont un moyen très configurable d’exécuter des workflows dans votre propre environnement local personnalisé. Vous pouvez exécuter des exécuteurs auto-hébergés localement ou dans le cloud. Vous pouvez également utiliser des exécuteurs auto-hébergés pour créer une configuration matérielle personnalisée avec davantage de puissance de traitement ou de mémoire pour exécuter des tâches plus volumineuses, installer les logiciels disponibles sur votre réseau local et choisir un système d’exploitation non proposé par GitHub.

GitHub Actions peut avoir des limites d’utilisation

GitHub Actions présente certaines limites d’utilisation en fonction de votre plan GitHub et selon que votre exécuteur est auto-hébergé ou hébergé par GitHub. Pour plus d’informations sur les limites d’utilisation, consultez Usage limits, billing, and administration dans la documentation GitHub.

Continuer