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

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

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.

27. Processus de développement

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

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