Objectifs
- Relier pipeline, stages, jobs, dépendances et runner/agent.
- Utiliser conditions et variables sans exposer de secret.
- Lire un workflow GitHub Actions et une pipeline GitLab CI.
- Reconnaître la structure d’un Jenkinsfile déclaratif.
Pipelines CI/CD
Une pipeline versionnée avec le code rend le workflow relisible et auditable. Les stages organisent les phases ; les jobs exécutent des steps sur des runners ou agents ; leurs dépendances et conditions contrôlent l’ordre et le périmètre.
Les variables portent la configuration non sensible. Les tokens, passwords et clés viennent du secret store de la plateforme, sont injectés au dernier moment, masqués dans les logs et accordés avec le moindre privilège.
Exemple GitHub Actions
Ce workflow se déclenche sur un push vers main et exécute un seul job sur un runner Ubuntu. Chaque step utilise une action réutilisable ou une commande du repository.
name: CI
on:
push:
branches:
- main
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Install dependencies
run: npm ci
- name: Build
run: npm run build
- name: Test
run: npm testLes actions tierces exécutent du code sur le runner. Utilisez des versions validées, maîtrisez leurs permissions et mettez-les à jour selon votre politique.
Mini exemple GitLab CI
stages fixe ici l’ordre build puis test. Chaque job choisit son stage et fournit les commandes de script. Le stage test ne commence que si le build requis réussit.
stages:
- build
- test
build:
stage: build
script:
- npm ci
- npm run build
test:
stage: test
script:
- npm testJenkinsfile déclaratif
Le bloc pipeline contient un agent et des stages. Chaque stage regroupe ses steps. Dans un environnement réel, l’agent doit être isolé, maintenu et limité aux credentials nécessaires.
pipeline {
agent any
stages {
stage('Build') {
steps {
sh 'npm ci'
sh 'npm run build'
}
}
stage('Test') {
steps {
sh 'npm test'
}
}
}
}Conditions, dépendances et sécurité
Une condition peut réserver le déploiement à main, à un tag ou à une approbation. Une dépendance garantit qu’un job attend un résultat antérieur. Gardez le workflow compréhensible et fail-fast sur les gates critiques.
- Ne jamais hardcoder un token ou password dans le YAML.
- Utiliser le secret store de GitHub, GitLab ou Jenkins et empêcher son affichage.
- Protéger main, exiger des reviews et limiter les droits du token de job.
- Isoler et mettre à jour les runners, surtout lorsqu’ils sont auto-hébergés.
- Préférer des credentials temporaires lorsque la plateforme le permet.
Erreur fréquente : transformer le YAML en script opaque
Mini résumé
- Stages, jobs et runners structurent l’exécution de la pipeline.
- GitHub Actions, GitLab CI et Jenkins expriment des concepts similaires avec des syntaxes différentes.
- Conditions et dépendances contrôlent quand et dans quel ordre les jobs s’exécutent.
- Secrets, actions tierces et runners exigent permissions minimales et maîtrise du code exécuté.
Outils associés
Construire une commande Terraform
Préparez une commande Terraform de pipeline et vérifiez son niveau de risque sans exécuter apply ou destroy.
Ouvrir l’outilConstruire une commande Ansible
Préparez une commande Ansible destinée à une automatisation et relisez sa cible, son inventory et ses options avant utilisation.
Ouvrir l’outilMini quiz
Trois questions pour vérifier les notions essentielles de la leçon.