Aller au contenu
English
Compte : non connecté, synchronisation possible Mon apprentissage
Selectionner le thème
English

Épreuve CI/CD : réparer une chaîne de livraison cassée

Par mis à jour le

Améliorer cette page

L'épreuve de fin de niveau vous remet une chaîne de livraison qui ment : sa pipeline est verte, une version est publiée, et pourtant presque tout y est faux. Vous avez une heure, sans indice, pour la rendre honnête, publier une version corrigée et la promouvoir jusqu'en production. Elle clôt le niveau « Comprendre et construire une chaîne de livraison » de la formation d'introduction aux pipelines : elle ne demande rien que le cœur n'ait enseigné, mais elle demande tout à la fois. La note porte sur l'état final de la forge et des deux environnements, jamais sur les commandes tapées.

  • Repérer ce qui rend une pipeline verte trompeuse
  • Rendre la chaîne honnête sans toucher aux tests
  • Publier une version corrigée et la promouvoir par son empreinte
  • Nommer les défauts de sécurité trouvés et leur correction

L'épreuve assemble les gestes du cœur de la formation, sans en ajouter. Les étapes dans le dépôt et les déclencheurs viennent de Étapes et déclencheurs ; la publication et l'empreinte de Artefacts ; la promotion, la configuration par environnement et l'injection de Environnements et promotion ; la révocation d'un jeton exposé de Les secrets dans les pipelines CI/CD ; l'épinglage et les surfaces d'attaque de Sécuriser une pipeline CI/CD.

Un seul savoir dépasse la formation : lire et corriger une fonction Python de quelques lignes, car le défaut que la pipeline cachait est dans le code. Si un de ces gestes vous manque, relisez la leçon correspondante avant de lancer le lab : l'épreuve ne donne aucun indice. Elle rappelle seulement où se gèrent jetons et secrets dans Forgejo, comme la leçon Artefacts, et demande de ne pas révoquer le jeton lab-…, qui sert à votre clone et au correcteur.

Le dépôt inventaire arrive dans l'état laissé par une équipe pressée. La liste ci-dessous dit ce qui sera vérifié ; elle ne dit pas où se trouvent les défauts, c'est à vous de les repérer en relisant la chaîne.

  • La pipeline d'intégration lance make lint, make test et make build, dans cet ordre, sans masquer aucun échec, avec chaque action épinglée par le SHA de son commit, sans afficher de secret, et ne publie que sur une étiquette v*.
  • main est verte, avec les tests et la recette make test d'origine : on corrige le code, pas le test.
  • Le jeton qui a fui est révoqué et remplacé dans le secret REGISTRE_JETON.
  • Une nouvelle version est publiée depuis une étiquette verte, la 1.0.0 étant immuable.
  • Le déploiement installe la version publiée sans la reconstruire, ses entrées passant par l'environnement ; la nouvelle version tourne en recette puis en production, avec la même empreinte, imposée pour la production.
  • Le fichier risques.md, à la racine du dépôt, nomme les défauts de sécurité trouvés et leur correction.

Chaque attendu est un test qui lit l'état de la forge (fichiers de main, statuts des pipelines, registre, jetons) et de la machine (journal des déploiements, artefacts installés, réponse de chaque environnement). Un contournement ne passe pas : modifier le test pour qu'il accepte le code faux, retirer l'étape make test ou la rendre tolérante à l'échec fait échouer la vérification correspondante.

Le fichier risques.md est contrôlé sur la présence de chaque défaut, pas sur la qualité de votre justification. Cette partie est une preuve que vous validez vous-même, pas une preuve attestée : relisez-la avec quelqu'un si vous le pouvez.

L'épreuve se joue dans la même machine virtuelle que les labs de la formation, avec la forge Forgejo et son runner. Elle se lance avec dsoxlab run level-exams-chaine après dsoxlab provision, puis se note avec dsoxlab check level-exams-chaine. L'installation de DSOXLab est décrite dans la documentation DSOXLab. Comptez une heure, et lancez-la quand les trois labs du cœur passent sans aide.

  • L'épreuve assemble les gestes du cœur, sans en ajouter, plus une correction de Python de quelques lignes.
  • Une pipeline verte ne prouve rien si elle masque un échec : on corrige le code, jamais le test.
  • La version 1.0.0 est immuable : une correction se publie sous un nouveau numéro, puis se promeut par son empreinte.
  • Un jeton lu dans un journal se révoque et se remplace ; le retirer du journal ne suffit pas.
  • La note lit l'état final ; risques.md reste une preuve que vous validez vous-même.

Ce projet vous est utile ?

Les guides, formations, quiz et labs restent gratuits. Si vous les utilisez régulièrement, vous pouvez contribuer à leur maintenance et à leur développement.

Devenir membre de soutien (nouvel onglet) Soutenir une fois (nouvel onglet) En savoir plus

Suivez aussi le projet sur LinkedIn