La présentation aborde les principes et outils de l'intégration continue utilisés au sein de Transcontinental Médias, mettant en avant l'importance de l'intégration fréquente du code, des tests automatisés et des outils tels que Maven, Hudson et Sonar. L'intégration continue améliore la collaboration, la détection des erreurs et la productivité, tout en nécessitant un changement de paradigme de la part des développeurs et gestionnaires. Les bénéfices incluent une meilleure intégration système, une réduction des risques et une agilité accrue dans le processus de développement logiciel.

1. Principes et outils d'intégration continue Medias Transcontinental Février 2011

2. Objectifs de la présentation Sensibiliser les participants aux principes, pratiques et outils utilisées par l'équipe technique de réalisation (concepteurs et développeurs) L'intégration continue Concepteurs, développeurs, intégrateurs Premiers utilisateurs Impact sur leur pratique Analystes et gestionnaires Mieux comprendre le métier des développeurs Apprécier comment les outils peuvent servir à assurer un suivi de l'évolution du travail de l'équipe Rapprocher les différents métiers

3. L’intégration continue (IC) « Un changement de paradigme qui affecte notre façon d’envisager le développement et la livraison de composantes logicielles »

4. Définition (in English) Continuous Integration is a software development practice where members of a team integrate their work frequently . Each integration is verified by an automated build (including tests) to detect integration errors as quickly as possible. (…) this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly . -- Martin Fowler

5. Les principaux outils d’IC chez Transcontinental Médias Eclipse IDE SVN Gestionnaire de sources Maven Outil de build Nexus Gestionnaire de dépôts d’artéfacts Hudson Gestionnaire de builds automatisés Sonar Analyseur de qualité du code

6. Si une image vaut mille mots… … alors une animation vaut …

7. Une journée d’intégration continue

8. L'environnement d'IC chez Transcontinental Medias

9. Maven: Outil de build et de gestion des dépendances

10. Nexus: Gestionnaire de dépôts d’artéfacts

11. Hudson: Gestionnaire de builds automatisés

12. Sonar: Service d'analyse de la qualité et de la conformité du code

13. Mise en garde p/r Hudson et Sonar Ne doivent pas être utilisés comme outils de surveillance et de répression Ce sont des outils qui doivent servir A améliorer la qualité du travail de l'équipe de concepteurs/développeurs A faciliter le travail des gestionnaires (suivi de l'avancement des travaux) Les objectifs et les métriques de qualité doivent être ceux de l'équipe au grand complet, pas seulement des concepteurs et développeurs Responsabilité collective

14. Eclipse: IDE Un seul projet Eclipse! Dépendances sur de nombreux jars internes et de tierces parties Aucune anomalie de compilation

15. Les pratiques importantes de l’IC Pratique Description Promouvoir le code fréquemment Effectuer des promotions de code au moins une fois par jour. Ne jamais promouvoir du code brisé Ne jamais faire la promotion de code ne compilant pas ou échouant un test. Réparer immédiatement le code brisé Même si la responsabilité est collective, le développeur qui a fait la dernière promotion doit s’impliquer dans la correction du code. Écrire des tests automatisés S’assurer que le logiciel fonctionne en utilisant des tests automatisés. Exécuter ces tests avec les builds automatisés. Tous les tests et inspections doivent passer Pas 90%, pas 95% mais tous (100%) les tests doivent passer avant de promouvoir du code modifié. Exécuter des builds privés Pour éviter des échecs d’intégration, effectuer un merge avec les changements des autres développeurs et exécuter un build d’intégration local (build privé). Éviter de récupérer du code brisé Si le build est en échec, vous perdrez du temps si vous récupérez le code de la voûte centrale. Attendez que la correction soit complétée ou participez à l’effort de correction avant de récupérer le code le plus récent.

16. Principes de base de l’IC Toutes les dépendances sont gérées avec Maven Toute promotion de code dans SVN déclenche un build par Hudson qui dépose les artéfacts résultants dans Nexus Les binaires sont tous dans Nexus, jamais dans SVN Les dépendances sont sur les artéfacts pas sur les projets Eclipse Tous les acteurs (développeurs, intégrateurs, gestionnaires de config, sysadmina etc.) doivent d’abord utiliser ce qui se trouve dans le dépôt Nexus, pas les sources qui se trouvent dans SVN

17. Avantages liés aux pratiques d’IC Environnement de développement (Eclipse) simplifié, allégé et plus réactif Moins de projets dans l’IDE Moins de temps à monter des « espaces de travail » Moins de risques d’être affecté par les changements des autres Gestion automatisée des dépendances, des sources et de la javadoc Modules internes (Transco) Modules de tiers Développeurs ne sont pas affectés par les instabilités causées par un build brisé Gains de productivité Moins de temps consacré à des activités de mise en place, de mise à jour, de configuration et de correction des environnements de développement Plus d’agilité

18. Bénéfices liés à l’IC 1. Feedback amélioré. L’IC expose la progresssion constante réalisée par les équipes.

19. Bénéfices liés à l’IC 2. Meilleure détection des erreurs. L’IC permet la détection et la résolution des anomalies généralement quelques minutes après leur introduction. Cela requiert le maintien d’une suite de tests unitaires avec un niveau de couverture approprié.

20. Bénéfices liés à l’IC 3. Collaboration améliorée. L’IC permet aux développeurs de collaborer efficacement et en toute confiance et sécurité. Ils savent qu’ils peuvent modifier du code, intégrer les modifications et déterminer rapidement l’impact des changements.

21. Bénéfices liés à l’IC 4. Meilleure intégration système En intégrant continuellement, on sait qu’on est toujours en mesure de “builder” et déployer l’ensemble du système ce qui réduit les surprises dûes aux problèmes d’intégration en fin de cycle.

22. Bénéfices liés à l’IC 5. Réduction du nombre de changements simultanés devant être fusionnés et testés

23. Bénéfices liés à l’IC 6. Réduction du nombre d’erreurs identifiées durant les tests d'intégration. Tous les conflits sont résolus par la personne la plus apte à le faire, avant la diffusion des changements.

24. Bénéfices liés à l’IC 7. Atténuation des risques techniques. On dispose en tout temps d’un système à jour et prêt à être utilisé pour effectuer les tests fonctionnels et les tests d'intégration.

25. Bénéfices liés à l’IC 8. Réduction des risques (et de la gestion du risque) En intégrant continuellement le système, on connait avec précision quelle fonctionnalité est implantée et fonctionnelle, ce qui améliore notre habilité à prédire ce qui sera livré et quand ça le sera.

26. Exigences de l’IC Demande un changement de paradigme de la part des développeurs, intégrateurs, gestionnaires de config Nouveaux savoirs-faire (Maven, Hudson, Nexus, Sonar) à maîtriser Le métier change et évolue Il faut travailler « intelligemment » Au lieu de l’approche « build all », on utilise le « build if changed » (or affected by change) Chaque artéfact/composante ou regroupement de composante a son propre cycle de versionnement et de release

27. Processus de développement

28. Processus de livraison et d'acceptation (1)

29. Processus de livraison et d'acceptation (2)

30. Merci de votre attention!