L'Intégration Continue n'est pas une histoire de tout ou rien. En fait, mettre en place l'IC au sein d'une organisation suit un chemin qui vous fera passer par différentes phases. A chacune de ces phases se rattachent des améliorations de l'infrastructure technique, mais aussi, et c'est peut-être le plus important, des améliorations des pratiques et de la culture de l'équipe de développement elle-même. Dans les paragraphes qui vont suivre j'ai essayé d'esquisser chacune de ces phases.
Au tout début, l'équipe n'a pas de serveur central de build quelqu'il soit. Le logiciel est construit manuellement sur la machine du développeur, même si cela peut être réalisé par un script Ant ou equivalent. Le code source peut être enregistré dans un gestionnaire de configuration centralisé, mais les développeurs n'ont pas l'habitude de commiter leurs modifications régulièrement. Peu de temps avant la prochaine livraison prévue, un développeur intègre manuellement les modifications, une opération qui produit beaucoup de peine et de soufffrance.
Dans cette phase, l'équipe possède un serveur de build et des builds automatisés sont exécutés régulièrement (généralement la nuit). Ce build compile tout simplement le code car il n'existe pas de tests unitaires pertinents et répétables. En effet, les tests automatisés, même s'ils sont écrits, ne font pas partie du processus de build, et peuvent ne pas s'exécuter correctement du tout. Cependant, maintenant les développeurs commitent leurs modifications régulièrement au moins à la fin de la journée. Si un développeur commite des modifications de code qui entrent en conflit avec le travail d'un autre développeur, le serveur de build avertit l'équipe par mail le lendemain matin. Toutefois, l'équipe ne se sert du serveur de build qu'à titre informatif — ils ne se sentent pas obligés de réparer un build en échec immédiatement, et le build peut rester en échec pendant plusieurs jours sur le serveur de build.
L'équipe commence à prendre l'Intégration Continue et les tests au sérieux. Le serveur de build est configuré pour lancer un build dès qu'un nouveau code est commité dans l'outil de gestion de configuration et les membres de l'équipe peuvent facilement voir quelles sont les modifications du code qui correspondent à chaque build et de quel problème elles traitent. A cela s'ajoute le fait que le script de build compile l'application et lance une série de tests unitaires ou d'intégration automatisés. En plus des emails, le serveur de build avertit aussi les membres de l'équipe des problèmes d'intégration en utilisant des canaux plus proactifs tel que la messagerie instantanée. Les builds en echec sont maintenant réparés rapidement.
Des métriques de qualité et de couverture de code automatisées sont maintenant mesurées pour aider à évaluer la qualité du code et (jusqu'à un certain point) la pertinence et l'efficacité des tests. Le build mesurant la qualité de code produit aussi automatiquement la documentation de l'API de l'application. Tout ceci permet à l'équipe de maintenir un code de très bonne qualité, alertant les membres de l'équipe en cas de dérive des bonnes pratiques de tests. L'équipe a aussi monté un “build radiator”, un tableau de bord qui présente l'état du projet sur un écran visible de l'ensemble des membres de l'équipe.
Les bénéfices de l'Intégration Continue sont étroitement liés à de solides pratiques de test. De nos jours, des techniques comme le développement piloté par les tests sont très utilisées ce qui améliore la confiance que l'on peut avoir dans le résultat d'un build automatisé. L'application n'est plus simplement compilée et testée, mais si les tests passent, elle est automatiquement déployée sur un serveur d'application pour des tests plus complets de bout en bout et des tests de performance.
Le Développment piloté par les tests d'acceptance est utilisé, guidant les efforts de développement et fournissant des rapports de haut niveau sur l'état du projet. Ces tests automatisés profitent des outils issus du monde du Développement piloté par le comportement (BDD) et du Développement piloté par les tests d'acceptance non seulement comme outils de tests mais aussi comme outils de communication et de documentation, en produisant des rapports de tests utilisant les termes métier qu'un non-développeur peut comprendre. Puisque ces tests de haut-niveau sont automatisés dès le début du processus de développement, ils permettent de savoir très simplement quelles sont les fonctionnalités qui sont réalisées et celles qu'il reste à faire. L'application est automatiquement déployée sur un environnement de test pour l'équipe qualité (QA) soit à chaque modification soit tous les soirs ; une version peut être déployée (ou “promue”) pour des tests de conformité utilisateurs et il est possible de la déployer dans des environnements de production au moyen d'un build lancé manuellement quand les testeurs la considère prête. L'équipe peut aussi utiliser le serveur de build pour revenir en arrière d'une version en cas de catastrophe.
La confiance dans les tests unitaires, d'intégration et d'acceptance automatisés est telle que les équipes peuvent utiliser les techniques de déploiement continu développées dans les phases précédentes pour pousser les modifications directement en production.
La progression entre les niveaux décrite ici est approximative et peut ne pas correspondre exactement à des situations dans le monde réel. Par exemple, vous pouvez tout à fait introduire des tests de l'interface web avant de mettre en places les métriques de qualité de code et les rapports sur la couverture de code. Cependant, cela devrait vous donner une idée globale de la stratégie d'Intégration Continue à mettre en oeuvre dans une organisation du monde réel.