L’intégration continue

C'est quoi l'intégration continue ?

La première chose à savoir c'est : l’intégration continue n’est pas un outil mais plutôt une pratique !!

Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day.

Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible.

Le principe est simple: récupérer régulièrement la dernière version du code source et exécuter des scripts de construction, des tests voire même le déploiement de l’application… afin de détecter le plus tôt possible les régressions et les bugs et d’avoir régulièrement un environnement mis à jour avec la dernière version de l’application.

Pour quoi l’intégration continue ?

L’intégration continue  permet de:

• Minimiser le risque et détecter facilement et rapidement les bugs et les régressions dans les différents niveaux : unitaire, intégration, fonctionnel et déploiement … Exemple : par simple comparaison entre deux versions nous pouvons  déterminer le code susceptible d’être à l’origine de la régression.
• Avoir, en permanence,  une  version stable du code ainsi qu’un déploiement fréquent  ce qui permet aux utilisateurs de tester le code rapidement et d’avoir donc des feedback rapides.
• Réagir à temps par rapport aux erreurs d’intégration et ne pas laisser déraper le projet : réduction du coût de correction des bugs, à condition bien entendu de l'existence de tests... La fréquence élevée d'intégration diminue le délai de détection d'un bug.
• Augmenter l’efficacité des développeurs : le fait que l'on sache immédiatement qu'une tâche a échoué apporte une certaine discipline au développeur. Finis les "t’as oublié de commuter un fichier !", "t'as.... (fait n'importe quoi) " . Ces problèmes prennent toujours plus de temps à trouver leur origine qu'à les corriger (suppression d'un fichier encore utilisé quelque part ailleurs, modification de code impactant un autre composant, ...). Avec l'intégration continue on connaît tout de suite la nature et l'origine du problème.
• Garantir la qualité de code produit.
• Avoir une connaissance plus concrète de l'état d'avancement du développement.

Les serveurs de d’intégration les plus connus

• Cruise Control : open source et gratuit, très connu, très documenté.
• Hudson : open source et gratuit.
• Continuum : opensource et gratuit soutenu par la fondation Apache.
• Bamboo : opensource et payant.

Best practices

• Avant de commiter le développeur doit tout d’abord lancer un build sur sa machine et exécuter les tests automatiques. Ensuite, récupérer les modifications sur le Source Code Manager (SCM). Il n’est pas question de commiter avant de récupérer la dernière version du code et vérifier, en locale, qu’il n’y a pas de conflits ou d’erreurs (le build et les tests s’exécutent sans erreurs). Une fois qu’on a une version synchronisée sans conflits et sans erreurs, le développeur peut commiter son code.
• Une compilation complète (clean and build) permet d’éviter pas mal de problèmes.
• Il’est très important de savoir que touts les intérêts de l’intégration continue dépendent de la fréquence de l’exécution du processus (check-in, compilation, build….), donc une  fréquence élevée des intégrations est obligatoire (au moins toutes les nuits).
• Des commits fréquents dans le SCM permettent d’éviter les conflits avec d’autres commits. Un  commit après chaque évolution mineure est fortement recommandé.
• Ne pas laisser traîné les échecs d’intégration, corriger les erreurs le plus tôt possible permet d’éviter l’effet cumulatif des bugs.