Les pipelines CI/CD complexes peuvent devenir difficiles à gérer, entraînant des inefficacités.
Cela peut conduire à des erreurs coûteuses et des pertes de temps si chaque étape n’est pas correctement structurée.
Cet article explore l’organisation efficace des jobs et steps pour optimiser la gestion des pipelines CI/CD.
Devenez expert en gestion de dépôts et automatisez avec GitHub Actions!
Introduction aux Jobs et Steps CI/CD
Comme nous l’avons vu dans la partie précédente, Un Job est une unité de travail dans une pipeline CI/CD, composée de plusieurs Steps . Chaque Step est une tâche ou commande spécifique, exécutée de manière séquentielle pour accomplir l’objectif du Job. Cette structure modulaire permet de gérer efficacement les processus CI/CD en s’assurant que chaque étape est terminée avant de passer à la suivante.
Configurer Jobs dans un pipeline CI/CD
Lors de la configuration d’un Job dans une pipeline CI/CD, certaines clés essentielles doivent être définies pour garantir le bon fonctionnement du processus. La clé principale à utiliser est jobs, qui regroupe les différents Jobs dans le pipeline.
- Clé :jobs
La clé jobs regroupe tous les Jobs dans le pipeline, chaque Job ayant sa propre configuration. Les Jobs sont les unités de travail essentielles pour structurer le pipeline.
- ID unique
Chaque Job doit avoir un identifiant unique pour le différencier des autres. Cet ID est utilisé pour gérer les dépendances et l’exécution conditionnelle des Jobs.
- Runs-on
La clé runs-on spécifie l’environnement d’exécution du Job, en choisissant l’image du runner (ex. Linux, Windows). Ce choix est crucial pour assurer la compatibilité et les performances des tâches.
Voici un exemple pour bien concretiser ce concept :
jobs:
build:
name: Build and testymlyml
runs-on: ubuntu-latest
steps:
- name: Checkout committed
uses: actions/checkout@v2
- name: Install dependencies
run: npm install
La clé jobs :
La clé jobs est utilisée pour définir tous les Jobs dans le pipeline. Ici, il y a un Job nommé build qui est configuré sous cette clé.
ID « build » :
‘ build ‘ est l’identifiant unique (ID) du Job. Il sert à différencier ce Job des autres dans la configuration. Cet ID peut être utilisé pour faire référence à ce Job ailleurs dans le fichier YAML
Runs-on : ubuntu-latest :
La clé runs-on spécifie l’environnement d’exécution du Job. Ici, ubuntu-latest indique que ce Job sera exécuté sur la dernière version stable d’Ubuntu. Cela signifie que toutes les tâches définies sous steps seront exécutées dans cet environnement Linux.
Steps avancés : Personnalisation CI/CD
Un Step avancé peut inclure des paramètres supplémentaires pour personnaliser son comportement. Par exemple, nous pourrions vouloir contrôler l’environnement dans lequel une commande est exécutée, spécifier des variables d’environnement, ou définir des conditions sous lesquelles le Step doit être exécuté. Voici un exemple de Step avancé avec options personnalisées :
jobs:
build:
runs-on: ubuntu-latest
steps:
- name: Run tests only on the main branch
if: github.ref == 'refs/heads/main'
run: npm run test
env:
NODE_ENV: production
API_KEY: ${{ secrets.API_KEY }}
Explication de example :
- Nom du Step : »Run tests only on the main branch » est le nom du Step, ce qui le rend facilement identifiable.
- Condition (if :): Le Step ne s’exécute que si la branche actuelle est main. Cela garantit que les tests ne s’exécutent pas sur d’autres branches, optimisant ainsi les ressources.
- Commande (run :): npm run test exécute les tests de l’application.
- Variables d’environnement (env :): Les variablesNODE_ENV et API_KEYsont définies pour ce Step spécifique, permettant de passer des configurations critiques ou des secrets nécessaires à l’exécution des tests.
Communication entre jobs et steps
Dans un pipeline CI/CD, les jobs et les steps jouent des rôles distincts mais complémentaires. La communication entre ces éléments est essentielle pour garantir que les informations circulent correctement, que ce soit pour partager des résultats intermédiaires, des artefacts, ou des variables d’environnement. Cette communication fluide permet de construire des pipelines efficaces et modulaires, où chaque étape dépend des résultats des précédentes.
Voici un exemple pour mieux comprendre cette section :
jobs:
setup:
runs-on: ubuntu-latest
outputs:
data: ${{ steps.setup.outputs.result }}
steps:
- name: Setup environment
id: setup
run: echo "::set-output name=result::success"
build:
needs: setup
runs-on: ubuntu-latest
steps:
- name: Build project
run: echo "Using data from setup: ${{ needs.setup.outputs.data }}"
Explication du code :
Le workflow est composé de deux tâches (jobs) : setup et build . Les tâches s’exécutent dans des environnements Ubuntu et sont configurées pour s’exécuter en série, où build dépend de la réussite de setup.
Tâche setup:
- runs-on :ubuntu-latest: Cette tâche s’exécute sur un environnement Ubuntu récent.
- outputs :Définit les sorties de cette tâche que d’autres tâches peuvent utiliser. Ici, la sortie nomméedataest définie à partir de la sortieresultde l’étapesetup.
- steps :Liste des étapes à exécuter dans cette tâche.
- name :Setup environment: Nom de l’étape.
- id :setup :Identifiant de l’étape, utilisé pour référencer ses sorties.
- run :echo « ::set-output name=result::success »: Exécute une commande shell pour définir une sortie nommée result avec la valeur success. Cette valeur est ensuite accessible comme steps.setup.outputs.result.
Tâche build :
- needs :setup: Indique que cette tâche dépend de la tâche setup. Cela signifie quebuildne s’exécutera que si setup a réussi.
- runs-on :ubuntu-latest: Comme pour la tâche setup, cette tâche s’exécute sur un environnement Ubuntu récent.
- steps :Liste des étapes à exécuter dans cette tâche.
- name :Build project: Nom de l’étape.
- run :echo « Using data from setup: ${{ needs.setup.outputs.data }} »: Exécute une commandeshellpour afficher les données obtenues de la tâche setup. La syntaxe
${{ needs.setup.outputs.data }} est utilisée pour accéder à la sortie data définie dans la tâche setup.
Gestions des erreurs et le délais d’exécution
Dans un workflow, il est fréquent de rencontrer des erreurs qui peuvent bloquer l’exécution du workflow ou générer des problèmes. Le sujet de cette section est la gestion du contrôle de la continuité et des délais d’exécution (timeouts) des étapes.
Voici un exemple qui nous montre comment gérer les erreurs et le délai d’exécution :
steps:
- name: Long running test
run: ./run-log-test.sh
continue-on-error: true
timeout-minutes: 15
- continue-on-error :Permet au workflow de continuer même si l’étape échoue (utile pour les étapes dont l’échec ne doit pas stopper le workflow).
- timeout-minutes :Définit une limite de temps pour l’exécution de l’étape, après laquelle l’étape sera arrêtée si elle n’est pas terminée.
Mettre en pratique les jobs et les steps dans un workflow.
Pour mettre en pratique les notions de steps et de jobs, nous allons exécuter un script Node.js pour déclencher un workflow. Cela nous permettra de mieux comprendre et expérimenter ces concepts. Pour ce faire, nous créerons quatre fichiers.
Tout d’abord, nous allons créer un fichier index.js à la racine de notre projet, avec le contenu suivant, qui renverra la chaîne de caractères « Hello world » :
function greet(){
return "Hello world";
}
module.exports = greet
Ensuite, créez le fichier test.js dans le même dossier avec le contenu suivant. Ce fichier importe le fichier index.js et met en place une condition basée sur la sortie de ce fichier :
const greet = require('./index');
console.log("Running tests ...");
if (greet() === "Hello world") {
console.log("Test passed");
process.exit(0);
} else {
console.log("Test failed");
process.exit(1);
}
Ensuite, créez le fichier package.json , qui contiendra les dépendances et les scripts pour les fichiers précédents, avec le contenu suivant :
{"name":"Simple-node-app","version":"1.0.0","description":"A simple Node.js application","main":"index.js","scripts":{"test":"node test.js","build":"echo 'Building ... Nothing to compile'"},"author":"","license":"ISC"}
Enfin, créez le workflow pour automatiser les étapes de construction et de test. Pour ce faire, créez un fichier nommé build-and-test-nodejs.yml.
name: index.js build and test
on:
push:
branches: [main]
pull_request:
branches: [main]
jobs:
build:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v4
- name: Setup Node.js
uses: actions/setup-node@v4
with:
node-version: '20'
- name: Install dependencies
run: npm install
- name: Run build
run: npm run build
test:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v4
- name: Setup Node.js
uses: actions/setup-node@v4
with:
node-version: '20'
- name: Install dependencies
run: npm install
- name: Run tests
run: npm run test
Ce workflow comprend deux jobs associés aux événements de push et de pull request sur la branche principale du dépôt. Autrement dit, chaque fois qu’un push ou une pull request est effectué, le workflow sera déclenché. Les deux jobs, build et test , sont indépendants et s’exécuteront donc en parallèle.
Maintenant, effectuons le commit et le push vers le dépôt distant pour déclencher le workflow en utilisant les commandes nécessaires que nous avons déjà abordées dans le chapitre précédent.
Après avoir effectué le push , le workflow est déclenché. Les deux jobs sont alors visibles et exécutés dans le dépôt, sous la section Actions.
Nous pouvons vérifier en détail l’exécution des jobs de la manière suivante : par exemple, pour le job build , voici la liste des steps exécutés :
Parfait, nous avons complété avec succès la pratique des jobs et des steps.
Formez-vous gratuitement avec Alphorm !
Maîtrisez les compétences clés en IT grâce à nos formations gratuites et accélérez votre carrière dès aujourd'hui.
FAQ
Qu'est-ce qu'un job dans une pipeline CI/CD ?
Comment configurer un job dans une pipeline CI/CD ?
Qu'est-ce qu'un step avancé dans un job CI/CD ?
Comment les jobs et steps communiquent-ils dans un pipeline CI/CD ?
Comment gérer les erreurs et le délai d'exécution dans un workflow CI/CD ?
Conclusion
En comprenant les concepts de jobs et steps dans une pipeline CI/CD, vous pouvez optimiser votre flux de développement. Quelle partie du processus CI/CD aimeriez-vous approfondir davantage ?
