A l'époque des projets en V et des diagrammes de Gantt, avant l'introduction des pratiques de l'IC, une équipe de développement dépensait son temps et son énergie sans compter durant la phase amenant à la livraison, appelée Phase d'Intégration. Durant cette phase, toutes les modifications apportées au code par les développeurs ou de petites équipes étaient rassemblées puis aggrégées et fusionnées en un produit fonctionnel. Ce travail était dur, intégrant ainsi des mois de modifications qui entraient en conflit. Il était très difficile d'anticiper les problèmes qui allaient surgir, et encore plus de les corriger car cela impliquait de reprendre du code qui avait été écrit des semaines, voire des mois auparavant. Ce douloureux processus, plein de risques et de dangers, amenait souvent des retards significatifs de livraison, des coûts supplémentaires et, au final, des clients mécontents. L'Intégration Continue est née comme une réponse à ces problèmes.
L'Intégration Continue, dans sa forme la plus simple, se compose d'un outil qui surveille les modifications de code dans votre gestionnaire de configuration. Dès qu'un changement est détecté, cet outil va automatiquement compiler et tester votre application. Si la moindre erreur arrive alors l'outil va immédiatement avertir les développeurs afin qu'ils puissent tout de suite corriger le problème.
Mais l'Intégration Continue est bien plus que cela. L'Intégration Continue peut aussi suivre la santé de votre projet en surveillant la qualité du code et les métriques de couverture et ainsi aider à maintenir la dette technique à un niveau bas et à abaisser les coûts de maintenance. Rendre visible publiquement les métriques de qualité de code encourage les développeurs à être fiers de la qualité de leur code et à essayer de toujours l'améliorer. Combinée à une suite de tests d'acceptance automatisés, l'IC peut aussi se transformer en outil de communication en affichant une image claire de l'état des développements en cours. Et elle peut simplifier et accélerer la livraison en vous aidant à automatiser le processus de déploiement, vous permettant de déployer la dernière version de votre application soit automatiquement soit d'un simple clic.
Dans le fond, l'Intégration Continue c'est réduire les risques en fournissant des retours rapides. En premier lieu, de par sa conception, elle permet d'identifier et de corriger les problèmes d'intégration et les regressions plus rapidement ce qui permet de livrer plus facilement et avec moins de bogues. En donnant une meilleure visibilité sur l'état du projet à tous les membres de l'équipe, techniques comme non-techniques, l'Intégration Continue facilite la communication au sein de l'équipe et encourage la collaboration pour résoudre les problèmes ainsi que l'amélioration du processus. Et, en automatisant le processus de déploiement, l'Intégration Continue vous permet de mettre votre logiciel dans les mains des testeurs et des utilisateurs finaux plus rapidement, avec plus de fiabilité et avec moins d'efforts.
Ce concept de déploiement automatisé est important. En effet, si vous poussez ce concept de déploiement automatisé à sa conclusion logique, vous pourriez mettre en production tout build qui passerait sans encombre les tests automatisés nécessaires. Cette pratique de déployer en production tous les builds ayant réussi est appelée communément Déploiement Continu.
Cependant, une approche pure du Déploiement Continu n'est pas toujours souhaitable. Par exemple, de nombreux utilisateurs n'apprécieraient pas d'avoir une nouvelle version disponible plusieurs fois par semaine et préféreraient un cycle de livraison plus prévisible (et transparent). Des considérations commerciales et marketing peuvent aussi entrer en compte pour déterminer quand une nouvelle version doit être déployée.
La notion de Livraison Continue est très proche de cette idée de Déploiement Continu en prenant en compte ces considérations. Lors d'une Livraison Continue tout build qui a réussi à passer les tests automatisés pertinents et les contrôles qualité peut virtuellement être déployé en production au moyen d'un processus lancé par un simple clic, et ainsi se retrouver dans les mains de l'utilisateur final en quelques minutes. Cependant, ce processus n'est pas automatique : c'est au métier, plutôt qu'à l'Informatique de décider quel est le moment opportun pour livrer les dernières modifications.
Ainsi les techniques d'Intégration Continue, et plus particulièrement le Déploiement Continu et la Livraison Continue, permettent d'apporter la valeur à l'utilisateur final plus rapidement. Combien de temps faut-il à votre équipe pour mettre une petite modification du code en production ? Dans ce temps quelle est la part des problèmes qui auraient pu être corrigés plus tôt si vous aviez su quelles modifications faisait Joe au bout du couloir ? Quelle part est prise par le pénible travail des équipes de la qualité pour tester manuellement ? Combien d'étapes manuelles, dont les secrets ne sont connus que de quelques initiés seulement, sont nécessaires à un déploiement ? L'Intégration Continue n'est pas la solution miracle, elle permet de rationaliser certains de ces problèmes.
Mais l'Intégration Continue est tout autant une mentalité que des outils. Pour tirer un maximum de profit de l'IC, une équipe doit adopter un comportement IC. Par exemple, vos projets doivent avoir un build fiable, reproductible et automatisé, sans intervention humaine. La correction des builds en erreur devrait être une priorité absolue, et ne devrait pas être oubliée dans un coin. Le processus de déploiement devrait être automatisé, sans étape manuelle. Et puisque la confiance que vous mettez dans votre serveur d'intégration dépend en grande partie de la qualité de vos tests, l'équipe doit mettre l'accent sur la qualité des tests et des pratiques associées.
Dans ce livre nous verrons comment mettre en œuvre une solution d'Intégration Continue robuste et complète avec Jenkins ou Hudson.