4. Rappels sur l’intégration continue Présentation So@t License Creative Commons 2.0 – Share Alike Enjeux de l’intégration continue
5. Rappels sur l’intégration continue Enjeux de l’intégration continue Présentation So@t License Creative Commons 2.0 – Share Alike Source: http://www.agitar.com/solutions/why_unit_testing.html Les 5% de bugs découverts après la release représentent 95% des coûts de correction
6.
7.
8. Rappels sur l’intégration continue Enjeux de l’intégration continue Présentation So@t License Creative Commons 2.0 – Share Alike Spécifications Développement, correction d’une fonctionnalité Implémentation de la fonctionnalité ou correction et des tests unitaires Compilation privée du module ou projet Enregistrement dans le SCM 1 Détection du besoin d’intégration Evènements envoyés par le SCM Scrutation du SCM Périodique, manuelle 2 Intégration Mise à jour depuis le SCM Compilation du projet Tests unitaires et d’intégration Analyses de la qualité de code 3 Historisation et publication des résultats Enregistrement des résultats Génération des rapports Notifications des résultats Publication de l’artéfact 4
9.
10.
11.
12.
13.
14. Rappels sur l’intégration continue Présentation So@t License Creative Commons 2.0 – Share Alike Et dans la pratique ?
15.
16.
17.
18. Rappels sur l’intégration continue Et dans la pratique ? – En quelques mots… Présentation So@t License Creative Commons 2.0 – Share Alike Accueil d’un nouveau développeur Enregistrement des modifications Compilation, tests Analyses de code Détection du besoin d’intégration Chargement de modifications Production de code Outil de compilation Intégration continue Gestion de configuration Gestion de dépendances Compilations privées pom.xml
51. Exemple de mise en œuvre Plan d’action – le processus de développement Présentation So@t License Creative Commons 2.0 – Share Alike Processus de développement développement TU NOK commit TU OK Compilation + TU Compilation ou TU NOK Compilation + TU + Déploiement Auto Dev-integ Compilation + TU + TF + Déploiement Auto TU-Dev-integ Compilation ou TU ou TF NOK Compilation ou TU ou TF NOK TU = tests unitaires TF = tests fonctionnels Poste développeur SVN TeamCity
52.
53. Exemple de mise en œuvre Plan d’action – Le processus de livraison Présentation So@t License Creative Commons 2.0 – Share Alike Processus de livraison Production Livrable Environnement installé Déploiement Correction TF NOK Livraison Environnement Installé TF = tests fonctionnels Déploiement si TF OK sur env. dev-intégration Tests MOA NOK Poste Livreur (job Serveur CI) Pré-Intégration Intégration Développeurs
Quels sont les ingrédients techniques pour la réussite d’un projet? L’effet tunnel Traçabilité de la vie du projet => Livraison régulière, … Et qd il y a bcp de développeurs, qu’est ce qui consomme du tps? L’intégration => qui doit être indépendante de l’env Reproductivité de l’environnement de compilation Reproductivité de l’environnement technique
l’intégration est une activité complexe… l’effort augmente significativement avec : le nombre d’artéfacts, les tests d’intégration…et leurs définitions, le nombre d’erreurs, la qualité du code, … le temps écoulé depuis la dernière intégration. l’intégration continue est apparue avec les pratiques XP avec comme motivation de remplacer les grosses et longues phases d’intégration en fin de projet par des phases plus petites et plus fréquentes l’idée principale : réduire au minimum l’effort d’intégration de l’application sans altérer le processus de développement logiciel
trois composants : Un outil de construction automatisée Tel qu'Ant ou Maven2, permettant aussi bien au développeur qu'à l'outil d'intégration continue de construire tout ou partie du système. Un unique système de gestion de sources, Tel que CVS ou Subversion, contenant les sources et l'historique des modifications apportées par les développeurs sur le système. A chaque mise à jour, le serveur d'intégration continue charge les modifications et exécute la construction complète du système. Un serveur d'intégration continue, Tels que Hudson, Bamboo, Continuum ou Cruise Control. Son rôle est de détecter les mises à jour sur le système de gestion de sources, d'exécuter le cas échéant la construction du système et de notifier l'équipe de développement du résultat
Parler du build : pas de définition (totalement) précise…! le build peut aller de la compilation, incrémentale, à la génération d’un package en passant par la génération de fichiers de source, le lancement de tests (unitaires, d’intégration…), l’analyse du code source, la génération d’un site web et de rapports… d’une certaine manière, le build englobe l’ensemble des actions souhaitées prenant en entrée des fichiers sources pour produire un résultat souhaité. généralement, nous attendons d’un outil de build qu’il puisse automatiser et optimiser ces actions.
Pas d’intégration continue sans stratégie de build totalement opérationnelle
l'effet psychologique sur le développeur n'est pas négligeable, d'autant plus si l'on se trouve dans un contexte d'urgence. la qualité des corrections est bien souvent délaissée au profit de la rapidité de mise en œuvre. pour éviter de telles situations, dans une démarche d'intégration continue, LA tâche prioritaire lorsqu'un bogue est découvert est de le corriger.
import (only available in Maven 2.0.9 or later) This scope is only used on a dependency of type pom in the < dependencyManagement> section. It indicates that the specified POM should be replaced with the dependencies in that POM's <dependencyManagement> section. Since they are replaced, dependencies with a scope of import do not actually participate in limiting the transitivity of a dependency.