Intégration Continue
Last updated
Last updated
L'intégration continue permet de vérifier à chaque changement de code que celui-ci fonctionne correctement sur une environnement identique à celui de production et sans perturber les autres fonctionnalités.
En eXtreme Programming, il est recommandé d'intégrer le plus fréquemment possible de petits changements afin d'en constater les conséquences le plus rapidement possible.
Chez Wishtack, suite à un changement, nous avons constaté une fuite mémoire sur l'environnement d'intégration après quelques minutes.
Le diagnostic et la correction ont pris quelques secondes :
Récupération de l'identifiant du changement (i.e. : commit git) ayant introduit la fuite mémoire directement depuis l'outil de Monitoring.
Analyse du changement (contenu du commit).
Il s'agissait d'un commit où seule une ligne avait changé pour intégrer une librairie externe victime de fuite mémoire.
Nous nous sommes débarrassé de la librairie pour trouver une solution alternative.
Combien de temps et de claviers cassés cela aurait couté si la fuite avait été découverte à la livraison après plusieurs mois de développement ?
Netflix raconte une fuite mémoire assez surprenante qui leur a couté une énergie considérable :
A chaque modification, le développeur Check-In son code sur le Repository.
A chaque Check-In, le produit est rebuild automatiquement et les résultats sont publiés. Les résultats doivent être accessibles à toute l'équipe.
En cas de succès, les tests automatisés sont exécutés et les résultats publiés.
En cas de succès, les serveurs d'intégration sont mis à jour.
Toutes les parties prenantes (développeurs, clients etc...) peuvent évaluer la dernière version.
