Du commit à la mise en production

Leçon 1
40 min
Module 1 : Comprendre le chemin de livraison

Leçon 1 sur 15 · CI/CD, tests et mises en production sûresDu commit à la mise en production

Aperçu du cours

1. Comprendre le chemin de livraison

2. Créer un pipeline CI reproductible

3. Gérer les environnements et les secrets

4. Mettre en production les changements d'IA et de base de données

5. Rétablir et maintenir le processus de mise en production

Ce que vous saurez faire

Un changement n’est pas terminé quand il fonctionne sur votre ordinateur. Il est terminé quand il atteint les utilisateurs, par des étapes qu’une machine répète toujours de la même façon. Apprenez ces étapes avec un vrai changement. Voyez ce qui bloque un mauvais changement à chacune.

Avant de commencerCe qu’il faut savoir et avoir sous la mainEnviron 40 minutes

Ce que vous devez savoir

Les branches et les demandes de tirage, avec une source et une cible, présentées dans Les étapes d’une demande de tirage : ce qu’est une demande de tirage du cours L’essentiel de Git et du développement en équipe.
Les étiquettes et les numéros de version, présentés dans Branches de version et étiquettes : l’équipe publie une version du cours sur Git.
Une image, son étiquette, son empreinte et un registre, présentés dans Registre et déploiement : Registre, dépôt et étiquette du cours L’essentiel de Docker et du nuage pour les développeurs en IA.
Une révision d’une application conteneurisée, présentée dans Configuration opérationnelle : exemple détaillé : appliquer le fichier (parcours réel) du cours sur Docker.
Une vérification sommaire, présentée dans Vérifier et supprimer : tests de bon fonctionnement : ce que ce déploiement doit prouver du cours sur Docker.

Ce qu’il vous faut sur votre ordinateur

Un navigateur Web. Tout le contenu de cette leçon se trouve sur les pages publiques du dépôt de référence Nextia-Intelligence/ticket-api-ci. Vous n’avez pas besoin de vous connecter.
Pour les commandes facultatives : un terminal avec curl et Python 3 (du cours Créer et déployer votre première API). Elles lisent l’API publique de GitHub, qui ne nécessite aucun compte.
Votre API de billets de soutien du cours sur Docker, dans ~/projects/ticket-api (Windows : $HOME\projects\ticket-api). Cette leçon ne la modifie pas. Si elle manque ou ne fonctionne plus, copiez l’instantané end-of-m05 du cours sur Docker, comme dans Utiliser un instantané.
Vous n’avez pas encore besoin d’un compte GitHub ni d’Azure. Le module 2 crée votre propre dépôt avec un compte GitHub gratuit. Azure est facultatif dans tout le cours.

Exécuté avec GitHub Actions (exécuteurs ubuntu-24.04) dans le dépôt public Nextia-Intelligence/ticket-api-ci, et Azure CLI 2.88.0 dans canadacentral. Les commandes de cette leçon ont été exécutées avec curl et Python 3.14 sur macOS. Les étapes pour Windows n’ont pas été testées.

Six minutes d’un commit aux utilisateurs

Amira est responsable de ticket-api, l’API de billets de soutien des cours sur les API et sur Docker. Le 7 octobre 2026 à 18 h 20, elle a poussé un commit (enregistrement d’un changement). Il contenait un meilleur classificateur, keywords-1.1, désactivé par défaut. À 18 h 26, la production l’exécutait. Entre ces deux moments, personne n’a construit quoi que ce soit, copié un fichier ou saisi une commande de déploiement. Amira a fait deux choses : elle a fusionné une demande de tirage et approuvé un déploiement.

Une machine a fait le reste, dans un ordre fixe :

Elle a vérifié le changement sur la branche.
Après la fusion, elle a revérifié le changement sur main et construit une image.
Elle a déployé cette image dans une copie de test du service, puis l’y a vérifiée.
Après l’approbation d’Amira, elle a déployé la même image en production, puis l’a revérifiée.

Chaque étape peut bloquer le changement. Si une vérification échoue, l’étape suivante ne démarre pas.

L’intégration continue, ou CI, est la première moitié : chaque changement est fusionné fréquemment dans la branche principale. Une machine le vérifie à chaque poussée. La CD est la deuxième moitié : une machine amène le résultat vérifié aux environnements où il s’exécute. Un pipeline est tout le chemin automatisé, du commit à la production. Ce cours construit un pipeline pour l’API de billets. Chaque leçon montre le vrai pipeline du dépôt de référence.

Livraison ou déploiement

CD a deux sens, et les équipes les confondent :

	Livraison continue	Déploiement continu
Après la réussite des vérifications	Chaque changement peut passer en production.	Chaque changement passe en production.
Qui décide pour la production	Une personne approuve.	Le pipeline. Personne n’approuve.
Dans ce cours	Oui : la production attend une personne responsable de la révision.	Non.

L’API de billets utilise la livraison continue. Le service de soutien dépend des priorités qu’elle attribue, et un nouveau classificateur les modifie. Une personne lit le résultat en préproduction et décide. Les étapes automatiques sont les mêmes dans les deux cas. Seule la dernière barrière diffère.

Le vocabulaire, sur le vrai pipeline

Le dépôt de référence utilise GitHub Actions, le service CI/CD de GitHub. D’autres services, comme Azure DevOps Pipelines et GitLab CI, utilisent les mêmes idées sous d’autres noms. Le module 2 montre leurs équivalents dans Azure DevOps.

Deux flux de travail. Déclencheur : poussée vers main, la fusion de la demande de tirage no 3. Il démarre le flux de travail CI, fichier .github/workflows/ci.yml, avec deux tâches. La tâche de vérification du style, de test, d'audit et d'évaluation s'exécute sur l'exécuteur ubuntu-24.04, une nouvelle machine virtuelle. Ses étapes : installer les versions exactes, vérifier le style, exécuter les tests unitaires et de contrat, vérifier la sécurité, appliquer la barrière d'évaluation de l'IA, conserver les rapports. Elle produit l'artefact reports. La deuxième tâche, qui construit, teste sommairement et pousse l'image, dépend de la première. Elle s'exécute sur une autre nouvelle machine virtuelle. Ses étapes : construire l'image, la tester sommairement, pousser la même construction, écrire build-info.json, conserver les preuves de construction. Elle produit l'artefact build-info et l'image sha-7324d7b dans ghcr.io. Déclencheur : workflow_run, CI terminé sur main. Il démarre le flux de travail Deploy, fichier .github/workflows/deploy.yml, avec trois tâches : trouver l'image, puis déployer en préproduction dans l'environnement staging, puis déployer en production dans l'environnement production, qui attend une révision obligatoire. — Les deux flux de travail du dépôt de référence après la demande de tirage no 3. Chaque mot apparaît sur la partie qu'il désigne. Chaque tâche démarre sur une nouvelle machine virtuelle propre.

Chaque mot désigne une partie :

Mot	Ce que c’est	Dans le dépôt de référence
Déclencheur	L’événement qui démarre un flux de travail.	Une poussée vers `main`; une demande de tirage; « flux de travail CI terminé »; une poussée d’étiquette; une personne qui sélectionne Run workflow (exécuter le flux de travail).
Flux de travail	Un processus automatisé, dans un fichier YAML de `.github/workflows/`.	`ci.yml` (CI), `deploy.yml` (Deploy), `release.yml` (Release).
Tâche	Un groupe d’étapes exécutées sur une machine. Les tâches peuvent s’exécuter l’une après l’autre (`needs:`) ou simultanément.	« Vérifier le style, tester, auditer, évaluer »; « Construire, tester sommairement et pousser l’image ».
Étape	Une commande ou une action prédéfinie dans une tâche. Les étapes s’exécutent dans l’ordre. Si l’une échoue, la tâche s’arrête.	`ruff check .`; `pytest`; « Pousser la même construction ».
Exécuteur	La machine qui exécute une tâche. Un exécuteur hébergé est une nouvelle machine virtuelle (VM) pour chaque tâche, supprimée ensuite.	`ubuntu-24.04`, fourni par GitHub.
Artefact	Un fichier qu’une exécution conserve après la suppression de sa machine.	`reports` (résultats des tests); `build-info` (empreinte de l’image, commit et exécution).
Environnement	Un endroit où l’application s’exécute, avec ses propres paramètres, secrets et règles.	`staging` et `production`.

L’image de conteneur est aussi un artefact, au sens large : le résultat de construction que vous testez, puis déployez. Dans ce cours, « l’artefact » désigne l’image, et le pipeline l’identifie par son empreinte. Une étiquette peut pointer vers un autre contenu. Une empreinte ne le peut pas.

Deux autres mots liés aux environnements. La préproduction est une copie de la production où vous testez un changement dans les mêmes conditions, avant les utilisateurs. L’image en préproduction est une version candidate : elle devient la version publiée si elle réussit les vérifications. Une version publiée est une version offerte aux utilisateurs avec un nom, comme l’étiquette Git v1.2.0, et des notes sur les changements.

Exemple détaillé : suivre la demande de tirage no 3 jusqu’en production

La demande de tirage no 3 a pour source feature/classifier-1.1 et pour cible main. Amira ouvre la demande de tirage no 3 dans le navigateur :

Demande de tirage 3, classificateur keywords-1.1 derrière un indicateur, et barrière d'évaluation de l'IA. Fusionnée : usmanahmed99 a fusionné 1 commit dans main depuis feature/classifier-1.1. Les onglets montrent 1 commit et 2 vérifications. La description indique que keywords-1.1 est désactivé par défaut, CLASSIFIER_VERSION=1.0. Elle indique aussi que CI exécute maintenant la barrière d'évaluation sur les 33 billets réservés aux tests. Le commit 19d172b porte une coche verte. Plus bas : usmanahmed99 a fusionné le commit 7324d7b dans main, 2 vérifications réussies. — Demande de tirage no 3, sans connexion. L'en-tête nomme la cible (main) et la source (feature/classifier-1.1). Le commit 19d172b a réussi les deux vérifications; la fusion a créé le commit 7324d7b sur main. L’image est en anglais.

La page donne deux identifiants de commit : 19d172b, le commit sur la branche, et 7324d7b, le commit de fusion sur main. Chaque exécution du pipeline appartient à l’un d’eux. L’API publique de GitHub énumère les exécutions d’un commit. La sortie est courte si vous affichez seulement les champs nécessaires :

macOS et Linux
Windows

curl -s "https://api.github.com/repos/Nextia-Intelligence/ticket-api-ci/actions/runs?head_sha=7324d7b3ade618916d89d452bbe040c3fa630590" \
  | python3 -c "import json,sys; [print(r['id'], r['name'], r['event'], r['conclusion']) for r in json.load(sys.stdin)['workflow_runs']]"

curl.exe -s "https://api.github.com/repos/Nextia-Intelligence/ticket-api-ci/actions/runs?head_sha=7324d7b3ade618916d89d452bbe040c3fa630590" | python -c "import json,sys; [print(r['id'], r['name'], r['event'], r['conclusion']) for r in json.load(sys.stdin)['workflow_runs']]"

La sortie :

37666627403 Deploy workflow_run success
37666387332 CI push success
37666141730 CI pull_request success

Trois exécutions, la plus récente en premier. Lisez-les de bas en haut, avec les heures indiquées sur leurs pages :

Heure (UTC)	Ce qui s’est passé	Déclencheur	Preuve
18 h 20 min 56 s	Amira pousse `19d172b` vers `feature/classifier-1.1` et ouvre la demande de tirage vers `main`.		Demande de tirage no 3
18 h 21–18 h 22	CI vérifie la branche : les deux tâches réussissent (25 secondes chacune). L’image est construite et testée, sans être poussée.	`pull_request`	Exécution 37666141730
18 h 22 min 55 s	Amira fusionne. `main` reçoit le commit de fusion `7324d7b`.		Demande de tirage no 3
18 h 23–18 h 24	CI revérifie `main` (40 secondes), puis construit, teste sommairement et pousse l’image `sha-7324d7b` (47 secondes).	`push`	Exécution 37666387332
18 h 24 min 58 s	Deploy envoie l’image en préproduction et la vérifie sommairement (55 secondes).	`workflow_run`	Exécution 37666627403
18 h 25 min 53 s	La production attend une personne responsable de la révision. Amira approuve.		la même exécution
18 h 26 min 54 s	La production exécute la même image, et sa vérification sommaire réussit (53 secondes).		la même exécution

Pourquoi le pipeline vérifie-t-il le code deux fois? L’exécution de la demande de tirage vérifie la branche. Celle sur main vérifie le contenu de main après la fusion. Seule cette exécution produit l’image qui peut passer en production. Une exécution de demande de tirage ne pousse jamais d’image.

L’exécution Deploy montre le reste du chemin sur une seule page :

Exécution Deploy numéro 3, réussie, déclenchée par une exécution de flux de travail, commit 7324d7b, durée totale de 2 minutes 7 secondes. Le graphique de deploy.yml, sur workflow_run : trouver l'image, 4 secondes, puis staging / déployer en préproduction, 55 secondes, avec l'adresse de préproduction, puis production / déployer en production, 53 secondes, avec l'adresse de production. Plus bas, règles de protection du déploiement : usmanahmed99 a approuvé production, avec le commentaire : keywords-1.1 est désactivé par défaut (CLASSIFIER_VERSION=1.0). La préproduction a réussi. Approuvé. — Exécution Deploy 37666627403, sans connexion. Les trois tâches s'exécutent l'une après l'autre. L'approbation et son commentaire font partie du dossier de l'exécution. L’image est en anglais.

Les journaux (logs) exigent une connexion, mais les faits figurent dans l’exécution. La préproduction et la production ont toutes deux reçu ghcr.io/usmanahmed99/ticket-api-ci@sha256:e5157802…, l’empreinte poussée par CI pour 7324d7b. Les deux vérifications sommaires ont affiché les quatre mêmes lignes :

ok    health (200)
ok    ready (200)
ok    classify with the key (200)
ok    classify without a key (401)

L’approbation contient un commentaire qui explique pourquoi : le nouveau classificateur est désactivé par défaut, et la préproduction a réussi. Une personne qui approuve sans lire ne constitue pas une barrière.

Le changement est en production, mais ce n’est pas encore une version publiée. Une version publiée a un nom de version et des notes. Plus tard ce jour-là, v1.2.0 a inclus ce changement, avec des notes et l’empreinte de son image. Consultez la version publiée v1.2.0. La leçon 2 explique les étiquettes et les versions.

Le pipeline et ses barrières

Une barrière est un point qu’un changement franchit seulement si une condition est vraie. Chaque étape du chemin de la demande de tirage no 3 en possède une. Chaque barrière prévoit une sortie pour un changement qui échoue :

Flux de travail CI. 1, commit sur une branche : pousser vers feature/classifier-1.1 et ouvrir une demande de tirage vers main. Si quelqu'un pousse directement vers main, l'ensemble de règles le refuse. 2, vérifications de la demande de tirage : vérifier le style, tester, auditer, évaluer, puis construire et tester sommairement l'image, sans poussée. Si une vérification est rouge, la demande de tirage ne peut pas être fusionnée; corriger sur la branche. 3, fusion dans main : l'ensemble de règles Protect main exige deux vérifications obligatoires vertes et une branche à jour. Si la branche est bloquée ou en retard, aucune fusion; mettre la branche à jour et revérifier. 4, construire une seule fois sur main : les vérifications s'exécutent encore, puis construire, tester sommairement et pousser l'image sha-7324d7b, et enregistrer son empreinte. Si une tâche échoue, aucune image n'est poussée et il n'y a rien à déployer. Quand CI réussit sur main, le flux de travail Deploy démarre et lit l'empreinte. 5, préproduction : déployer l'empreinte, attendre la nouvelle révision, exécuter la vérification sommaire. Si la préproduction échoue, l'exécution s'arrête avant la production. 6, approbation : l'environnement production attend une révision obligatoire. En cas de refus ou d'absence de réponse, la production conserve son image. 7, production : déployer la même empreinte et réexécuter la vérification sommaire. Si elle échoue, déployer la dernière empreinte fonctionnelle. Un artefact : ghcr.io/usmanahmed99/ticket-api-ci@sha256:e5157802..., construit une seule fois à l'étape 4 et déployé par son empreinte aux étapes 5 et 7. Une étiquette de version comme v1.2.0 désigne la même empreinte; rien n'est reconstruit. — Le pipeline du dépôt de référence, du commit à la production, avec la sortie à chaque barrière. L'image est construite une seule fois, à l'étape 4. Chaque étape suivante utilise son empreinte.

Regardez ce qui ne figure pas dans l’image. Aucune étape ne construit une deuxième image pour la production. Aucune étape ne copie des fichiers vers un serveur. Personne n’exécute une commande que le pipeline n’a pas enregistrée. Si la préproduction et la production exécutaient deux constructions différentes, un test en préproduction ne prouverait rien pour la production. Le module 2 construit l’image une seule fois; le module 3 la promeut par son empreinte.

Toutes les barrières ne sont pas des vérifications que vous écrivez. Les étapes 1 et 3 sont des règles du dépôt (un ensemble de règles, créé au module 2). L’étape 6 est une règle de l’environnement (module 3). La leçon 3 de ce module détermine les vérifications exécutées aux étapes 2 et 4.

Exercice guidé : retracer un changement vous-même

Retracez la PR no 3 avec votre navigateur et votre terminal. Le but est de trouver toutes les exécutions d’un changement et l’image arrivée en production.

Ouvrez la PR no 3. Notez la branche source, la branche cible et le commit de fusion.
Sélectionnez l’onglet Checks (vérifications). Notez les noms des deux vérifications.
Exécutez la commande curl de l’exemple détaillé. Vérifiez que vous obtenez trois exécutions.
Ouvrez l’exécution CI associée à l’événement push (poussée) : https://github.com/Nextia-Intelligence/ticket-api-ci/actions/runs/37666387332. Regardez le graphique des tâches. Quelle tâche s’est exécutée en premier?

Listez les tâches de l’exécution Deploy avec leurs heures :

macOS et Linux
Windows

curl -s https://api.github.com/repos/Nextia-Intelligence/ticket-api-ci/actions/runs/37666627403/jobs \
  | python3 -c "import json,sys; [print(j['name'], '|', j['conclusion'], '|', j['started_at'][11:19], '-', j['completed_at'][11:19]) for j in json.load(sys.stdin)['jobs']]"

curl.exe -s https://api.github.com/repos/Nextia-Intelligence/ticket-api-ci/actions/runs/37666627403/jobs | python -c "import json,sys; [print(j['name'], '|', j['conclusion'], '|', j['started_at'][11:19], '-', j['completed_at'][11:19]) for j in json.load(sys.stdin)['jobs']]"

La sortie :

Find the image | success | 18:24:50 - 18:24:54
staging / Deploy to staging | success | 18:24:58 - 18:25:53
production / Deploy to production | success | 18:26:01 - 18:26:54

Regardez l’écart entre la préproduction et la production. Que s’est-il passé pendant ces 8 secondes?
Ouvrez l’exécution Deploy. Trouvez qui a approuvé la production, et pourquoi.

Si curl affiche API rate limit exceeded (limite de requêtes API dépassée), attendez une heure ou utilisez seulement le navigateur. GitHub permet 60 requêtes par heure sans connexion.

Afficher les réponses attendues

Source feature/classifier-1.1, cible main, commit de fusion 7324d7b.
« Lint, test, audit, evaluate » (vérifier le style, tester, auditer, évaluer) et « Build, smoke-test and push the image » (construire, tester sommairement et pousser l’image). Ce sont les noms des deux tâches du flux de travail CI.
37666627403 Deploy, 37666387332 CI push, 37666141730 CI pull_request, toutes avec le résultat success (réussite).
« Lint, test, audit, evaluate » s’est exécutée en premier. La tâche de l’image démarre seulement quand la tâche de vérification réussit (needs: checks).
Comme indiqué.
La production attendait la personne chargée de la révision obligatoire, et Amira a approuvé. L’attente a été courte parce qu’elle était prête. Une attente réelle peut durer des heures, et l’exécution reste en attente pendant ce temps.
usmanahmed99 (le compte d’Amira dans le test) a approuvé, avec le commentaire « keywords-1.1 is off by default (CLASSIFIER_VERSION=1.0). Staging passed. Approved. » (keywords-1.1 est désactivé par défaut (CLASSIFIER_VERSION=1.0). La préproduction a réussi. Approuvé.)

À vous de jouer : retracer la mise en production 1.2.0

La PR no 5 a pour source feature/score-field et pour cible main. Elle a ajouté le champ score et est devenue la version 1.2.0. Son commit de fusion est c3c7135ec035fc0f7990a23a111ca4d460830d01. Trouvez ses exécutions avec la même commande curl et ce commit. Répondez ensuite : quels flux de travail se sont exécutés, et lequel ne s’est pas exécuté pour la PR no 3? Quelle empreinte est arrivée en production? Où trouvez-vous cette empreinte sans vous connecter?

Afficher la réponse

La sortie (7 octobre 2026) :

37667587273 Release push success
37667574234 Deploy workflow_run success
37667326873 CI push success

Un troisième flux de travail s’est exécuté : Release (mise en production), déclenché par la poussée de l’étiquette v1.2.0. La poussée d’une étiquette est aussi un déclencheur. La page de la mise en production v1.2.0 se termine par l’image : ghcr.io/usmanahmed99/ticket-api-ci@sha256:bd2316b56067c738199d6203a23845c97fb7b85b550379411eddd7cc6a2ddab8 (tag 1.2.0). L’exécution Deploy a envoyé la même empreinte en préproduction et en production. Le commentaire d’approbation indique « Release 1.2.0: staging smoke checks passed. keywords-1.1 stays off in production for now. » (Mise en production 1.2.0 : les vérifications sommaires en préproduction ont réussi. keywords-1.1 reste désactivé en production pour le moment.) Le flux de travail Release n’a rien construit : il a donné un nom de version à l’image construite par CI. Le module 3 montre comment.

Cette liste ne contient aucune exécution pull_request (demande de tirage). Les exécutions de la PR appartiennent au commit de la branche, pas au commit de fusion. GitHub l’a affichée pour la PR no 3; ne comptez pas là-dessus.

Erreur courante

La demande de tirage est verte, mais la production n'a pas changé

Symptôme : Sam voit les coches vertes sur une demande de tirage et dit au service de soutien que le nouveau classificateur fonctionne. Le service de soutien envoie un billet, et la réponse indique toujours keywords-1.0.

Cause : une demande de tirage verte signifie que la branche a réussi les vérifications. L’exécution de la demande de tirage construit et teste une image, mais ne la pousse pas. Il n’y a donc rien à déployer. Regardez les étapes de l’exécution de la PR no 3 :

Smoke-test the image before it leaves this runner success
Sign in to GitHub Container Registry skipped
Push the same build skipped

La production change seulement après la fusion, l’exécution CI sur main, la réussite en préproduction et l’approbation. Ici, il y a une deuxième raison : keywords-1.1 est désactivé par défaut. Même en production, les réponses indiquent keywords-1.0 jusqu’à ce qu’une personne définisse CLASSIFIER_VERSION=1.1 (module 4).

Solution : pour savoir ce qui fonctionne en production, lisez l’exécution Deploy, pas la demande de tirage. Vérifiez trois éléments : le commit de l’exécution, son résultat et l’empreinte déployée par la tâche de production. Dans le dépôt de référence, l’exécution Deploy de 7324d7b répond aux trois questions.

Pour un vrai service d’IA : « le modèle est déployé » peut vouloir dire « la demande de tirage a réussi », « l’image existe », « la préproduction l’exécute » ou « les utilisateurs le reçoivent ». Le service de soutien agit selon ce que les utilisateurs reçoivent. Précisez ce que vous voulez dire, avec l’exécution comme preuve.

Vérifiez votre compréhension

La production de l'API de billets attend une révision. Est-ce de la livraison continue ou du déploiement continu, et pourquoi l'équipe a-t-elle fait ce choix?

Afficher la réponse

De la livraison continue. Chaque changement qui réussit les vérifications peut aller en production, et les étapes sont automatiques. Toutefois, une personne approuve l’étape de production. L’équipe a fait ce choix parce qu’un changement de classificateur modifie les priorités utilisées par le service de soutien. Une personne lit le résultat de préproduction avant que les utilisateurs le voient. Avec le déploiement continu, le pipeline enverrait chaque changement réussi en production sans approbation.

Vérifiez votre compréhension

Prédisez : la tâche de préproduction d'une exécution Deploy échoue à sa première étape. Que devient la production, et quelle image exécute-t-elle ensuite?

Afficher la réponse

La tâche de production ne démarre pas, car elle s’exécute seulement après la réussite en préproduction. La production conserve l’image qu’elle avait déjà. Cela s’est produit dans le dépôt de référence. La première tentative de l’exécution Deploy 37664760027 a échoué à la connexion Azure en préproduction. La tâche de production avait le résultat skipped (ignorée). Le module 3 explique cette erreur et sa solution.

Récapitulatif

CI vérifie chaque changement à chaque poussée. CD transmet le résultat vérifié aux environnements. Un pipeline est le chemin complet.
Livraison continue : chaque changement réussi peut aller en production, après une approbation. Déploiement continu : il y va sans approbation. Ce cours utilise la livraison.
Un déclencheur démarre un flux de travail. Un flux de travail contient des tâches, une tâche contient des étapes, et chaque tâche utilise un nouvel exécuteur. Un artefact est un fichier qu’une exécution conserve. Un environnement est un endroit où l’application fonctionne, comme la préproduction ou la production.
La PR no 3 est passée d’un commit à la production en environ six minutes, franchissant une barrière à chaque étape. L’image a été construite une seule fois, et la préproduction et la production ont exécuté la même empreinte.
Une demande de tirage verte n’est pas un déploiement. Lisez l’exécution Deploy pour savoir ce que la production exécute.

Leçon suivante : Choisir un flux de branches