L'intégration Continue

Les 7 bonnes pratiques

L'intégration continue change la façon de coder des développeurs, chaque développeur doit changer ses habitudes. Il doit se forcer à commiter fréquemment, à écrire des tests pertinents. Il est vrai que pour des développeurs n'ayant pas cette habitude, cela demande de réels efforts. Je vais donc présenter les bonnes pratiques qu'un développeur doit connaitre s'il veut utiliser ce concept.

Commiter le code fréquemment

Souvent les développeurs ne veulent pas commiter leurs changements dans le code, soit ils ne veulent pas affecter le travail des autres, soit ils ne veulent pas être accusés d’avoir cassé le dernier build. Sauf que l'effort pour corriger par la suite sera plus grand. Il faut donc absolumment commiter ses changements le plus souvent possible.

Commiter du code bon

Une hypothèse dangereuse sur un projet est : tous les développeurs ne commitent jamais du code qui ne fonctionne pas. Les développeurs ne devront jamais commiter un code qui ne passe pas un test ou qui ne compile pas avec un autre code. Ils peuvent le vérifier avec la construction de builds privés

Résoudre les builds ratés rapidement

La cause d’un build qui a raté peut être n’importe quoi, cela peut être une erreur de compilation, un test qui ne passe pas, une métrique en dessous d’un certain seuil, un déploiement qui a échoué. Dans un contexte d’intégration continue, chaque erreur découverte doit être résolue immédiatement. Tous les développeurs qui ont commité précédemment et qui ont amené à un build raté doivent être impliqués dans la correction.

Écrire des tests automatisés

Il faut écrire des tests automatisés sinon le concept d'intégration continue ne sert à rien. Si le test ne passe pas, le build doit échouer.

Tous les tests et les rapports d'inspection doivent passer

Il arrive parfois qu'un développeur a avoir l’idée de commenter le test qui ne passe pas. Non seulement, il sera identifié rapidement avec le gestionnaire de sources, mais il participera à la baisse du taux de couverture de test du code.

Créer des builds privés

Pour éviter des builds intégrés qui échouent, les développeurs vont devoir émuler des builds d’intégration sur leurs postes. Ces builds privés vont permettre l’intégration de ses modifications avec celles des autres développeurs. Dans le cas d’un build privé réussi, qui inclut les récents changements des développeurs, le développeur pourra alors commiter ses changements qui auront alors très peu de chance d’aboutir à un build d’intégration raté.

Éviter de récupérer du mauvais code

Quand le build est dans le rouge sur le serveur d’intégration, les développeurs ne doivent pas récupérer la dernière version du code. Ils vont perdre du temps à corriger des erreurs qui ne sont pas les leurs. D’autant plus que, les développeurs responsables du build raté doivent travailler sur la résolution de leur code et vont le commiter de nouveau dans le gestionnaire de sources. Pour les autres développeurs, soit ils attendent que le changement soit commité, soit ils aident les développeurs qui travaillent sur le bug. On voit qu’il est très important, qu’à tout moment les développeurs doivent connaitre l’état du dernier build. L’envoi de courriel par le serveur d’intégration continue est donc très important.