Projet final et méthodologie

Projet final et méthodologie

1. Projet fil rouge : mettre une application en production

   Le projet est realized sur une petite application de votre choix, et vise un résultat vérifiable : la chaîne part d'un commit et mène jusqu'à une version déployée et traçable.

   Les six livrables

   1. Chaîne d'intégration : installation reproductible, qualité, tests, couverture minimale, matrice sur deux systèmes.
   2. Image de livraison : construction multi-étapes, utilisateur non privilégié, .dockerignore, empreinte reproductible vérifiée par deux constructions.
   3. Porte de qualité : analyse de dépendances et analyse d'image qui font échouer la chaîne, pas seulement rapportent.
   4. Déploiement : même artefact déployé sur deux environnements, configuration par variables, stratégie choisie et justifiée.
   5. Retour arrière : procédure écrite, testée, avec critère de décision.
   6. Traçabilité : l'identifiant de version remonte des journaux jusqu'au commit.

   Critères de réussite

   • un git clone suivi de la procédure documentée reconstruit tout, sans connaissance préalable ;
   • une modification du code, mergée, se retrouve déployée sans intervention manuelle ;
   • une pull request qui casse un test n'est pas mergée ;
   • le retour arrière est réalisé en moins de cinq minutes et vérifié.

2. Méthodologie et anti-patterns

   Par où commencer dans un projet existant

   1. un seul pytest qui passe en moins de cinq minutes ;
   2. la chaîne d'intégration, sans déploiement ;
   3. l'image reproductible ;
   4. la porte de qualité ;
   5. enfin le déploiement automatisé.

   Commencer par le déploiement automatisé sur une base non testée, c'est automatiser un accident : on ne saura jamais si un échec vient du code ou de l'infrastructure.

   Les anti-patterns les plus fréquents

   • Déployer depuis un poste : ce qui n'est pas dans la chaîne n'est pas reproductible.
   • Étiquette mouvante en production : on ne sait plus ce qui tourne.
   • Migration destructive en même temps que le code : plus de retour arrière possible.
   • Chaîne qui ne peut pas échouer : un contrôle qui rapporte sans bloquer ne protège rien.
   • Secret en clair dans le dépôt : il le restera dans l'historique.
   • Chaîne de 40 minutes : les développeurs arrêtent de la regarder, et l'évitent chaque jour.

   Faire adopter

   Une chaîne imposée sans explication est contournée. Le meilleur moyen de la faire adopter : rendre le délai entre « j'ai poussé » et « je sais si ça marche » plus court que le délai d'attente du prochain test manuel. L'adoption suit le bénéfice ressenti, pas la note de couverture.

   Outils à connaître

   • ruff, black, mypy : qualité Python
   • pytest : tests
   • trivy, pip-audit : sécurité des dépendances
   • hadolint : qualité des fichiers de construction
   • cosign : signature d'image

3. Ressources et évaluation

   Évaluation

   • Quiz à la fin de chaque module.
   • Atelier : la chaîne est réellement exécutée, et ses logs lus ensemble.
   • Projet final : les six livrables, évalués sur la reproductibilité et la vérifiabilité — pas sur le nombre d'exécutions.
   • Revue : chaque atelier est relu, et les remarques portent sur des points précis.

   Grille du projet

   • fonctionnel : la chaîne mène du commit au déploiement sans intervention
   • sûr : secrets gérés, permissions minimales, porte de qualité bloquante
   • reproductible : deux constructions donnent la même empreinte
   • exploitable : retour arrière testé, runbook écrit