Une mise en production un vendredi soir
Karim travaille pour une appli de livraison de repas à Bordeaux. Un vendredi à 18 h, il copie la nouvelle version sur le serveur à la main.
Il oublie un fichier. Les commandes ne passent plus pendant tout le service du soir.
Personne n'avait lancé les tests avant. Cette leçon montre comment une équipe confie ce travail à une machine.
À la fin de cette leçon
Remarque
Je peux décrire un pipeline qui teste le code puis le livre.
Mots clés
| Mot | Ce que ça veut dire |
|---|---|
| Dépôt | l'endroit partagé où l'équipe range son code et son historique |
| Test automatisé | un petit programme qui vérifie le code sans aide humaine |
| Pipeline | une suite d'étapes lancées par une machine, dans l'ordre |
| Intégration continue | tester chaque modification dès qu'elle arrive dans le dépôt |
| Déploiement | mettre une version à disposition des clients |
| Livraison continue | garder le code toujours prêt à être déployé |
Les cellules que les étudiants remplissent restent vides dans cet aperçu.
Une machine teste chaque modification
Avec l'intégration continue, chaque envoi de code dans le dépôt déclenche un pipeline.
Une machine récupère le code, installe ce qu'il faut et lance les tests automatisés. Si tout passe, elle fabrique l'image puis la déploie.
Personne ne copie de fichier à la main. Les étapes sont toujours les mêmes, dans le même ordre.
Un pipeline s'écrit dans un fichier
Les étapes sont décrites dans un fichier rangé avec le code. Beaucoup d'équipes utilisent GitHub Actions, dont les fichiers sont au format YAML.
Chaque ligne name: est une étape. Chaque ligne run: est la commande qu'elle lance.
Lancez le bloc ci-dessous. Bash écrit le fichier, puis en extrait les étapes.
Lire un fichier de pipeline
mkdir -p livraison-repas/.github/workflows && cd livraison-repas
cat > .github/workflows/livrer.yml <<'FIN'
name: Verifier et livrer
on: push
jobs:
livrer:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Installer
run: pip install -r requirements.txt
- name: Tester
run: pytest
- name: Construire l'image
run: docker build -t livraison-repas .
- name: Deployer
run: ./deployer.sh
FIN
# Les étapes, dans l'ordre où la machine les lance
grep "name:" .github/workflows/livrer.yml
# Quel évènement déclenche le pipeline ?
grep "on:" .github/workflows/livrer.yml
Une étape en échec arrête la chaîne
Un pipeline s'arrête à la première étape qui échoue. C'est voulu : une version qui ne passe pas les tests ne doit jamais arriver aux clients.
Le bloc suivant imite un pipeline en Bash. La commande set -e arrête tout dès qu'une commande échoue.
Lancez-le une fois, puis cassez le test comme le dit le commentaire.
Un pipeline qui s'arrête
set -e # s'arrête à la première commande qui échoue
etape() { echo "Étape : $1"; }
etape "Installer"
etape "Tester"
# Le test : un panier de 12 € plus 18 € de livraison doit faire 30 €
total=$((12 + 18))
test "$total" -eq 30
etape "Construire l'image"
etape "Déployer"
echo "Livré en production"
# Remplacez 30 par 31 dans le test, puis relancez.
# Les étapes Construire et Déployer ne s'affichent plus.
Une erreur fréquente
Attention
Beaucoup pensent qu'un pipeline vert prouve que le code n'a aucun défaut. Il prouve seulement que les tests écrits sont passés. Un cas que personne n'a testé peut encore casser en production. Quand un défaut passe, on ajoute le test qui l'aurait trouvé.
Livraison continue ou déploiement continu
| Après des tests réussis | Livraison continue | Déploiement continu |
|---|---|---|
| L'image est prête | Oui | Oui |
| Qui lance la mise en production | Une personne, d'un clic | Le pipeline, tout seul |
| Exemple | Une banque qui livre le mardi matin | Une appli qui livre vingt fois par jour |
Les cellules que les étudiants remplissent restent vides dans cet aperçu.