Skip to content

Latest commit

 

History

History
33 lines (23 loc) · 1.96 KB

README.md

File metadata and controls

33 lines (23 loc) · 1.96 KB

Ça part en prod ! Testez la résilience de votre appli par le chaos.

Avant toute chose : TP0 : Installation de l'environnement et récupération des sources

Introduction

"Bon, on a développé en interne une super application de gestion des compétences en architecture micro-service, on a fait une super recette fonctionnelle (sur les cas passants, faute de temps.. ça devrait suffire !), on a une couverture de TU au top, on a des super tests d'intégration, … Bref, on est super confiant pour partir en prod ! Mais au fait, quelqu’un a regardé si notre application allait tenir la charge ? Si elle était tolérante aux pannes ? Petit doute… Sait-on vraiment si notre application va être résiliente ou pas ?"

Chapitre 1

"Un stagiaire a touché au code source. Depuis, l'application bugue !! Pourtant, les tests unitaires passaient au vert ! Et la couverture de tests est à 100% sur l'ensemble de notre code métier ! A un mois de la MEP, doit t'on blâmer le stagiaire ou l'auteur des tests unitaires ? Comment aurait-on pu éviter d'avoir des TU inutiles ?”

TP1

Chapitre 2

"On a des doutes sur la tolérance aux pannes de notre application, en fait personne n'a jamais regardé !” Comment est ce qu'on peut faire un état des lieux de la situation ?"

TP2

Chapitre 3

"Le constat est fait : ok, notre applicatif répond.. mais est vraiment très sensibles aux pannes!” Comment rendre notre application vraiment résiliente ? Comment palier à ce genre de problèmes ?"

TP3

Conclusion

"Nous voilà rassurés, notre application est tolérante aux défaillances techniques, on va pouvoir aller en production beaucoup plus confiant! En plus, on a même pu challenger nos TU et récupérer des métriques au passage ! "