SP4 Intégration et métrologie Lot 4.1 Spécification de l'intégration

Transcription

1 Projet ANR-Verso 2008 UBIS «User centric»: ubiquité et Intégration de Services SP4 Intégration et métrologie Lot 4.1 Spécification de l'intégration Auteurs : Participants : Alban Richard Olivier Bourdon Version : V1.2 Date : 08/02/01 1 / 20

2 Historique du Document Version Date Modifications V1.0 20/01/11 Version initiale V1.1 01/02/11 1ère version livrée V1.2 08/02/11 2ème version livrée Abstract Dans ce document nous allons décrire l'ensemble du processus d'intégration tant d'un point de vue architectural que fonctionnel. En effet, dans un projet comme UBIS comprenant de multiples acteurs et faisant appel à de nombreuses briques technologiques, il est important de considérer l'intégration dans son ensemble et non comme s'est souvent le cas uniquement comme l'assemblage de «bouts de code» devenant la plateforme finale. Nous allons tout d'abord lister l'ensemble des choix technologiques mis en oeuvre dans le cadre de la plateforme d'un point de vue logiciel, expliquer brièvement leur fonction et les alternatives potentielles, justifier leur choix et enfin décrire les processus d'intégration Ce document traitera succinctement du cas des terminaux mobiles et des technologies qui leur sont associées en reprenant certaines parties du document réalisé par la société Snapp «Etude_Plateformes_Userware_Ubis.doc» concernant le choix de la plateforme de développement pour la partie terminaux mobiles. Nous aborderons de même rapidement les parties infrastructures matérielles (machines, routeurs virtuels [Virtuor], points d'accès WIFI,...) 2 / 20

3 Table des matières 1 CHOIX TECHNOLOGIQUES Composants de base Coeur de communication Conteneur Web «Standard» Conteneur Web SIP Technologies Web Files de messages EJB (Enterprise Java Beans) Sécurité Plateforme mobile Plateforme matérielle Vue d'ensemble SERVEUR D'INTEGRATION Service Web HTTP Service d'annuaire OpenLDAP Service VPN Service Web Conteneur Service de gestion de sources Subversion (SVN) Service de mise à jour automatique Schéma organisationnel du serveur d'intégration PLATEFORME D'INTEGRATION Mise en œuvre via machine virtuelle Ubuntu Utilisation et connexion utilisateur UBIS Enregistrement utilisateur sur le serveur d'intégration Connection au VPN Méthode innovante de mise à jour automatique PROCESSUS D'INTEGRATION ANNEXES Serveur SVN : principes de fonctionnement du gestionnaire de sources / 20

4 Index des illustrations Illustration 1: Logo OpenIMS Core... 5 Illustration 2: Logo GlassFish... 6 Illustration 3: Logo SailFin... 6 Illustration 4: Logos OpenSSO & OpenAM... 7 Illustration 5: Versions de Maemo/Meego... 8 Illustration 6: APIs Maemo/Meego... 8 Illustration 7: Plateforme Matérielle... 9 Illustration 8: Architecture Globale de la Plateforme Illustration 9: Logo Apache Illustration 10: Logo OpenLDAP Illustration 11: Logo ZK Illustration 12: Logo OpenVPN Illustration 13: Logo Subversion Illustration 14: Schéma Fonctionnel du Serveur d'intégration Illustration 15: Ecran d'invite utilisateur Ubuntu Illustration 16: Bureau de l'utilisateur UBIS Illustration 17: Formulaire d'inscription Illustration 18: Serveur Subversion Illustration 19: Exemples de modifications gérées avec SVN Illustration 20: SmartSVN: importation d'un repository SVN Illustration 21: SmartSVN: commandes principales / 20

5 1 Choix technologiques Dans cette partie, nous allons lister l'ensemble des choix technologiques faits dans le cadre du projet UBIS. Ceci est d'autant plus important que, dans le monde de l'open Source, les solutions possibles pour une problématique donnée sont nombreuses. Il est donc parfois difficile de distinguer celle qui correspond le mieux aux besoins du projet en cours tant d'un point de vue du nombre de fonctionnalités offertes que des possibilités d'extensions et de modifications, de la robustesse du code et du support que l'on peut obtenir en cas de problème. 1.1 Composants de base Ils constituent la base sur laquelle la plateforme sera bâtie Coeur de communication Il existe de nombreuses implémentations de coeur de communication basé sur le protocole SIP. Celle qui a été retenue ici est Open IMS Core disponible à l'adresse Illustration 1: Logo OpenIMS Core Cette technologie est livrée soit sous forme de code source soit sous forme de machine virtuelle de démonstration. Sa facilité de mise en oeuvre et d'utilisation ainsi que les nombreuses références de mise en application en ont fait le choix indiscutable. Nous avons retenu la version code source pour des raison évidentes de portabilité et extensibilité. Cependant afin d'uniformiser sa compilation et son utilisation ainsi que sa configuration, des scripts automatisant les processus de construction et de lancement des différents processus ont été ajoutés afin de permettre à toute personne de mettre en oeuvre cette brique de base de la plateforme sans demander aucune expertise préalable. 5 / 20

6 1.1.2 Conteneur Web «Standard» Le terme «standard» est à prendre ici en opposition au paragraphe Afin de pouvoir déployer les technologies décrites ci-après au paragraphe 1.2, il est nécessaire de posséder un conteneur d'applications Web basé sur la technologie J2EE c-a-d Java2 Enterprise Edition. Ici encore, plusieurs choix s'offrent à nous parmi: GlassFish (Open Source Sun/Oracle), Tomcat (OpenSource Fondation Apache), JBoss (OpenSource RedHat), JOnAS (OpenSource fondation Object Web) sans parler des offres commerciales (IBM WebSphere, BEA WebLogic, Oracle Application Server, ). Afin de minimiser les coûts d'apprentissage et de factoriser le code au maximum avec les parties SIP décrites ci-après, le choix qui s'impose de lui même est GlassFish: Encore une fois, que ce soit en s'appuyant sur les critères comparatifs entre la version 2 et la version 3 disponibles à la page mais surtout en considérant le fait que dans le cas d'un container commun avec la partie SIP la version 2 est celle qui est retenue. Ici aussi, des scripts de configuration et de lancement automatiques seront fournis afin que tout un chacun soit capable d'utiliser ce conteneur de la façon la plus simple possible et d'éviter par ailleurs les conflits de ports avec certains services administratifs fournis par Open IMS Core Conteneur Web SIP Illustration 2: Logo GlassFish Le projet SailFin ( est un conteneur web basé sur GlassFish 2.x (cf. paragraphe précédent), fournissant en plus une implémentation de stack SIP et permettant l'exécution d'applications SIP appelées SIPlets ou SIP servlets. Illustration 3: Logo SailFin Dans le cadre du projet UBIS, le protocole SIP doit être étendu afin de supporter des informations additionnelles (SIP+). C'est pourquoi, le fait que SailFin soit un composant OpenSource pour lequel nous disposons non seulement du code source mais aussi des procédures de fabrication a été un facteur déterminant dans le choix de cette technologie. Là encore, des scripts de compilation complètement automatiques seront fournis et suivront les mêmes principes que ceux cités au / 20

7 1.2 Technologies Web Nous allons ici faire la liste des technologies web qui seront utilisées dans les conteneurs Web et SIP GlassFish et SailFin cités ci-dessus Files de messages Afin que les différents composants puissent communiquer et échanger des messages selon les prérequis du projet UBIS (priorités, QOS, ) il est important de s'appuyer sur un mécanisme à la fois fiable et standardisé. Dans le monde Java, Sun Microsystems a proposé une spécification appelée Java Message Service (JMS) qui possède ce que l'on appelle plusieurs «implémentations de référence». En effet, il est très fréquent dans le monde OpenSource en général et dans le monde Java en particulier d'avoir besoin des fonctionnalités d'une librairie (Application Programming Interface aka. API) «standardisée» pour laquelle il est possible de trouver plusieurs implémentations, chacune apportant son lot de modifications et/ou améliorations. Dans le cas de JMS, on peut trouver l'implémentation de référence fournie par Sun Microsystems lui même ainsi que celle fournie par le conteneur GlassFish lui même, Open Message Queue mais aussi Active MQ Open JMS et plus récemment Apache QPID Cependant, désirant bénéficier d'un maximum de stabilité et fiabilité sans sacrifier la possibilité de modifier le code source si nécessaire, nous avons choisi l'implémentation de référence fournie par le conteneur GlassFish: Open Message Queue EJB (Enterprise Java Beans) Dans le cadre d'applications Java, les Enterprise Java Beans ou EJB constituent une des technologies de base très souvent employée. Ces composants logiciels dynamiques et distribués permettent facilement de représenter les données applicatives ainsi que les sessions des clients distants, ont la capacité d'être liés à un état (state-full) ou pas (stateless), de communiquer entre eux en utilisant différentes techniques et ceci qu'ils soient localisés dans un même conteneur ou pas Sécurité En ce qui concerne la partie sécurité, le projet UBIS a besoin de technologies dites de Single Sign On (authentification unique). Au démarrage du projet, Sun Microsystems disposait d'une offre OpenSource appelée OpenSSO qui a été retirée de l'offre catalogue lors du rachat de Sun par Oracle. Une nouvelle société fondée par des anciens employés de Sun qui travaillaient sur cette technologie a été créée, ForgeRock, et fournit maintenant l'équivalent disponible sous le nom de OpenAM Illustration 4: Logos OpenSSO & OpenAM Dans ce cadre, nous aurons besoin non seulement de la partie serveur mais aussi des codes des agents de connexion car celui-ci devra être adapté pour les besoins des services UBIS. 1.3 Plateforme mobile Tout au long du déroulement du projet UBIS, une des interrogations principales a été le choix de la plateforme mobile de «référence». En effet dans le monde mobile et comme expliqué par Nicolas Delabarre dans son document «Etude_Plateformes_Userware_Ubis.doc» écrit en septembre 2009, les premiers choix disponibles étaient: Java Micro Edition (JavaME par Sun/Oracle), Android (Google), iphone OS (Apple), Symbian (Nokia) et Windows Mobile (Microsoft). Chacune disposait de 7 / 20

8 ses points forts, de ses faiblesses et de son lot de spécificités et le choix n'était pas aisé. Considérant de plus que dans le cadre du projet UBIS, le UserWare possédait aussi une partie ordinateur de bureau/desktop, aucune des solutions pré-citées ne permettait de factoriser les développement entre la partie mobile et la partie desktop. Suite à la montée en puissance d'une solution appelée Maemo/Meego, basée sur un socle Linux Debian et promue par Nokia dans le cadre des développements pour son téléphone N900, une nouvelle évaluation technique à été entreprise par la société Snapp. Téléphones Version Maemo Année Nom de code Nokia x/2.x 2005/2006 Gregale Nokia N800 3.x 2007 Bora Nokia N810 4.x 2008 Diablo/Chinook Nokia N Fremantle Harmattan Illustration 5: Versions de Maemo/Meego En fait Meego dont la version 1.1 est sortie en Octobre 2010 grâce à l'effort commun de Nokia (côté Maemo) et Intel (pour Mobile Linux aka Moblin) se trouve être un «merge» entre Maemo 6 et Moblin 2. Un des principaux avantage de cette solution consiste dans la liste des librairies programmatiques (APIs) relativement standard qui sont disponibles à la fois du côté plateforme mobile mais aussi coté desktop Linux mais aussi dans l'environnement de développement lui même et basé sur la technologie Qt de TrollTech. C'est pourquoi l'écriture des parties UserWare devrait être largement simplifiée par l'utilisation des APIs communes aux mondes mobiles et desktop. Illustration 6: APIs Maemo/Meego 8 / 20

9 1.4 Plateforme matérielle Très brièvement voici le schéma de l'infrastructure mise en place au niveau matériel entre le site de Telecom ParisTech et SFR. Cette image fournie par Arnaud Le Maguer est bien évidemment sujette à modifications en fonction des besoins notamment ceux du démonstrateur. Illustration 7: Plateforme Matérielle Cette maquette matérielle peut être résumée comme suit : Liaison VPN IPsec point à point (2xCisco 1841) pour interconnexion Labsfr et Telecom ParisTech. Adressage de sous réseaux transitant dans le tunnel: Subnet dans le pool /22 côté Telecom ParisTech Subnet dans le pool /22 coté Labsfr Equipements Virtuor connectés coté Labsfr: 3 PhysicalNodes + 1 serveur console administration. Services proposés par le Labsfr: Transit Internet dédié Accès mobile 2G/3G avec APN dédiées diffusées sur le réseau de production Hébergement de serveurs virtuels (VMware) Hébergement de serveurs physiques Plateforme IPv4 et IPv6 (bout en bout) Administration: Console VMware: Administration «physique» des machines virtuelles (cœur IMS, serveur d intégration...) dans la Zone DMZ-Noc. Accès par VPN (client Cisco) Serveur d intégration (GlassFish, SVN, OpenLDAP ) dans la Zone DMZ. Accès http et VPN (OpenVPN) cf. page 11 9 / 20

10 1.5 Vue d'ensemble Afin de synthétiser l'ensemble des composants cités ci-dessus, voici un schéma englobant ces différentes technologies et les positionnant dans leur contextes respectifs. Une vue plus détaillé de la partie SaiFin peut être consultée sur Illustration 8: Architecture Globale de la Plateforme 10 / 20

11 2 Serveur d'intégration Afin de faciliter le travail de toutes les équipes participant à UBIS un serveur d'intégration à été mis à disposition dans l'infrastructure SFR sous forme de machine virtuelle exécutant un système d'exploitation Fedora Core bits et disponible sur l'adresse IP publique ubis.labsfr.com. Sur ce système, les services qui tournent sont les suivants: service Web HTTP ( service d'annuaire OpenLDAP ( service VPN ( service Web Conteneur ( service de gestion de sources Subversion (SVN) ( et service de mise à jour automatique (fonctionnalité propriétaire et innovante) Dans les paragraphes qui suivent, chacun de ces services va être décrit plus en détail. 2.1 Service Web HTTP Il est implémenté par le serveur httpd Apache natif dans la distribution Fedora Core et permet l'affichage des pages web contenant les informations d'utilisation et historiques des modifications des différents composants d'intégration (Machine virtuelle, programmes, ). On peut accéder aux informations qu'il contient en utilisant n'importe quel navigateur Web (Internet Explorer, Firefox, Chrome, Opera, Safari, ) et en utilisant l'url Dans certains cas, lors des processus automatiques de construction qui vont être évoqués dans un chapitre suivant, le service httpd permet aussi de récupérer des logiciels, scripts et/ou bouts de code qui ne peuvent être récupérés autrement de façon aisée (par exemple les versions de Java). Certaines zones de données de ce service peuvent éventuellement être sécurisés en utilisant le service d'annuaire décrit au paragraphe suivant. 2.2 Service d'annuaire OpenLDAP Illustration 9: Logo Apache Illustration 10: Logo OpenLDAP Ce service est représenté sous la forme du processus démon slapd lui aussi natif dans la distribution Fedora Core. Il permet d enregistrer des utilisateurs de façon centralisée et ainsi de fédérer les autorisations inhérentes à certains services de façon uniforme et ainsi éviter de nombreux duplicatas dans des fichiers de configuration épars. C'est ainsi qu'il est utilisé par les services de connexion au serveur (ssh), d'autorisation d'accès à certaines zones du serveur Web ci-dessus mais aussi et principalement d'identifier les clients du Virtual Private Network (VPN) décrit au 2.3 ainsi qu'au service de gestion de source SVN / 20

12 Illustration 11: Logo ZK Les données contenues par ce service d'annuaire sont entrées via un formulaire web utilisant de l' AJAX basé sur la technologie ZK ( et implémentée par le conteneur Web Service VPN Afin de ne pas laisser de potentiels pirates accéder aux services privés du serveur d'intégration (comme le gestionnaire de sources) puisque celui-ci est directement accessible sur Internet, la mise en place d'un serveur VPN s'impose et permet de restreindre l'utilisation de ces service sensibles aux seuls utilisateurs connectés via ce VPN. Pour cela nous utilisons le serveur OpenVPN de la distribution Fedora Core et qui sera de plus configuré de telle sorte qu'il utilisera les données utilisateurs contenues dans le service d'annuaire. Ce logiciel possédant par ailleurs des mécanismes simples de détection de connections entrantes, ceux-ci vont être mis à profit pour permettre la maintenance automatique de la machine virtuelle de développement décrite au 3 ainsi qu'au Service Web Conteneur Illustration 12: Logo OpenVPN L'ajout du logiciel GlassFish dans sa version 2.x permet non seulement l'utilisation de ZK (cf. 2.2 ) mais aussi le traitement des formulaires d'enregistrement des utilisateurs via l'extension Php Java Bridge ( Cette extension permet à un conteneur ne pouvant à priori pas exécuter du code PHP (ou autre langage de script) de le traiter de la même façon que tout serveur style Apache et son module mod_php. Ce conteneur sera aussi utilisé dans le cadre de l'intégration continue en lui ajoutant le module Hudson ( Ce dernier va permettre au serveur d'effectuer, par exemple, des tâches journalières de génération et aussi de test du code source et ainsi de le mettre à disposition de l'ensemble des membres du projet UBIS. 2.5 Service de gestion de sources Subversion (SVN) Illustration 13: Logo Subversion Dans le cadre d'un projet informatique quel qu'il soit, la gestion du code source est un élément important du processus de développement et d'intégration. Dans le domaine OpenSource de nombreuses solutions existent: CVS, SVN, GIT, Mercurial, Bazaar, certaines beaucoup plus anciennes que d'autres (CVS) et certaines relativement compliquées à mettre en oeuvre mais aussi à utiliser. C'est pourquoi le choix s'est naturellement porté sur Subversion/SVN qui est ici intégré au serveur via le module Apache livré dans la distribution Fedora Core: mod_dav-svn. Comme mentionné ci-dessus, il est configuré pour fonctionner avec l'authentification LDAP fournie par / 20

13 En plus de la version ligne de commande de manipulation des sources dans Subversion, des clients graphiques permettant une utilisation plus aisée sont disponibles sur toutes les plateformes classiques (MacOSX, Windows, Linux, ) et notamment SmartSVN qui est écrit en Java (cf D'autre part, cet outil de gestion de sources permet aussi l'émission de notification par lors de toute manipulation des sources et indiquant ainsi l'auteur et le contenu des modifications. Nous reparlerons de cet outil au chapitre Service de mise à jour automatique Comme indiqué au 2.3, il est possible d'utiliser des «déclencheurs» lorsqu'un client se connecte avec succès au VPN. Grâce à cette mécanique, le serveur d'intégration sera capable de mettre à jour les machines virtuelles distantes afin d'uniformiser toutes les plateformes de développement et de garantir ainsi le bon fonctionnement des processus de compilation et d'exécution des différents composants. Ce service sera plus amplement détaillé au chapitre Schéma organisationnel du serveur d'intégration Afin de clarifier les interactions entre les différents composants décrits ci-dessus voici un petit schéma permettant d'avoir une vue plus synthétique de l'ensemble des éléments et de leur interactions. Illustration 14: Schéma Fonctionnel du Serveur d'intégration 13 / 20

14 3 Plateforme d'intégration Afin d'uniformiser les plateformes d'intégration et de développement, il a été décidé de fournir une plateforme dite «de référence» sous la forme d'une machine virtuelle. Au format VMware, mais aussi utilisable via VirtualBox, les deux formats de virtualisation offrant des outils gratuits pour lancer ces environnements virtuels, cette machine est basée sur un OS de référence «stable» (Ubuntu 10.04) ainsi que l'ensemble des outils de développement nécessaires (Netbeans IDE, client SVN SmartSVN, client OpenVPN) et ceci dans une forme pré-configurée mais aussi entièrement maintenue de façon automatique grâce aux fonctionnalités décrites au 2.3 et Mise en œuvre via machine virtuelle Ubuntu Utilisation et connexion utilisateur UBIS Une fois le(s) binaire(s) récupéré(s), décompressé(s) et lancé(s) dans VMplayer ou VirtualBox selon les instructions disponibles à on découvre l'écran d'invite d'un Linux Ubuntu standard et qui comporte 2 utilisateurs : Illustration 15: Ecran d'invite utilisateur Ubuntu. L'un est entièrement réservé pour les tâches d'administration en possède les droits de super-utilisateur/root. L'autre est celui que doivent utiliser toutes les personnes étant amenées à développer dans le cadre d'ubis. Nous avons récupéré ci-dessous des informations déjà présentées par Akram Ben Hassen dans le document «La machine virtuelle de développement». Illustration 15: Ecran d'invite utilisateur Ubuntu Enregistrement utilisateur sur le serveur d'intégration Une fois le mot de passe entré, l'utilisateur arrive sur un bureau contenant par défaut les icônes donnant accès aux principaux outils de développement et d'utilisation de la plateforme: Illustration 16: Bureau de l'utilisateur UBIS. Tout d'abord en haut à gauche se situe l'outil permettant la création d'un nouvel utilisateur/développeur UBIS dans l'annuaire LDAP et pour ce faire se connecte au serveur d'intégration via 2.4. En double-cliquant sur cette icône on ouvre un navigateur web qui 14 / 20

15 affiche alors le formulaire d'enregistrement des nouveaux utilisateurs: Illustration 17: Formulaire d'inscription. Illustration 16: Bureau de l'utilisateur UBIS Illustration 17: Formulaire d'inscription 15 / 20

16 3.1.3 Connection au VPN La prise en compte du nouvel utilisateur étant immédiate et en utilisant la seconde icône en haut à gauche du bureau Illustration 16: Bureau de l'utilisateur UBIS, on peut alors se connecter directement au serveur d'intégration via le VPN. Durant cette étape, l'identifiant et le mot de passe seront demandé et vérifiés dans la fenêtre de connexion au VPN afin de garantir la sécurité des données. Une fois la connexion au VPN effectuée, l'utilisateur peut alors récupérer l'arbre de sources SVN en utilisant l'uri soit via la ligne de commande comme expliqué au 5.1 soit en utilisant la première icône en haut à droite du desktop pour lancer l'outil graphique SmartSVN. Pour plus d'informations se référer à Illustration 20: SmartSVN: importation d'un repository SVN et Illustration 21: SmartSVN: commandes principales Méthode innovante de mise à jour automatique Il est bien évident qu'une machine virtuelle de ce type, une fois déployée chez les différents acteurs participant au développement du projet UBIS, ne peut rester non modifiée, ne serait-ce que pour la mise à jour du système pour des raisons de faille de sécurité par exemple. Alors que nous pourrions nous baser sur des techniques existantes et/ou laisser l'utilisateur de la machine virtuelle faire lui même ces modifications, nous avons choisi d'innover et d'utiliser les propriétés offertes par le VPN lorsque les connexions sont établies. Grâce aux mécanismes disponibles dans OpenVPN, nous avons la possibilité de déclencher des actions côté serveur lors que la connexion d'un client distant est réussie en disposant de plus de l'identifiant unique (champ login dans l'entrée correspondant de l'annuaire LDAP). Ceci nous permet donc de mettre à jour certains fichiers critiques du système en poussant les versions corrigées depuis le serveur vers la VM cliente. Une fois ces modifications apportées avec succès et tant que le VPN reste ouvert, la VM effectue périodiquement des jobs de maintenance basés sur les fichiers poussés précédemment et contrôle via les journaux d'exécution que tout s'est bien déroulé. Si tel n'est pas le cas, alors les travaux qui n'ont pas été couronnés de succès seront rejoués à l'itération suivante. Il est bien sûr à noter que dans le cas d'un autre système VPN (IPSec, Tunnel, ) des fonctionnalités identiques sont soit disponibles de base soit implémentables à moindre coût. 16 / 20

17 4 Processus d'intégration Nous allons distinguer ici deux parties importantes du processus. La première concerne la gestion des sources et la seconde la génération et mise à disposition des composants issus de ces sources. 4.1 Gestion des sources Grâce au serveur Subversion, la grande majorité des fonctionnalités de gestion de source, à savoir gestion des modifications, historiques contenant dates et utilisateur, résolution ou indication des conflits en cas de modifications simultanées sur le même fichier, sont disponibles de base. D'autre part, une mécanique de notification a aussi été mise en place afin que les membres des différentes équipes soient informés de tout ajout, suppression et modification dans l'arbre de source (avec détail complet de ces modifications) 4.2 Gestion des composants Cette gestion peut être faite à deux endroits que nous allons expliciter maintenant Gestion au niveau de l'arbre de source En premier lieu et de façon assez traditionnelle chaque partie de code sera accompagnée de scripts et/ou makefiles/ant files/... permettant de reconstruire cette partie en fonction de la technologie utilisée (script pour les «bundles» comme OpenIMS Core par exemple, Makefiles pour les parties codées en C et Ant files pour les parties Java). Des scripts de plus haut niveau permettront quant à eux d'assembler le tout afin que l'ensemble soit gérable de la façon la plus simple possible Gestion au niveau du serveur d'intégration : intégration continue Au fil des années des techniques nouvelles ont émergé dans les processus de développement logiciel en prenant le nom d'intégration continue. Ces solutions constituent une «normalisation» de méthodes automatiques employées depuis bien des années mais productisées à l'extrême incorporant des mécaniques de reporting sophistiquées et très visuelles. Un exemple parmi tant d'autres mais qui à la particularité de s'adapter à tout style de projet, d'être embarcable dans un conteneur web style GlassFish et d'être compatible avec toutes les technologies citées précédemment dans ce document : Hudson Un bon point de départ consiste à lire les informations disponibles sur la page web et les différents liens qui en découlent. Il est cependant à noter que la priorité sera donnée aux développements inhérents à la partie afin de pouvoir mettre en œuvre le démonstrateur le plus rapidement possible et que la partie intégration continue viendra en sus. 5 Annexes 5.1 Serveur SVN : principes de fonctionnement du gestionnaire de sources Les informations complémentaires ci-après ont été reprises de la la documentation écrite par Akram Ben Hassen dans le document «La machine virtuelle de développement». 17 / 20

18 Illustration 18: Serveur Subversion Subversion (abréviation SVN) est un système de gestion de versions de fichiers qui permet de stocker des informations pour une ou plusieurs ressources informatiques mais aussi de récupérer toutes leurs versions intermédiaires ainsi que les différences entre les versions (définition wikipedia). Il travaille sur une arborescence de fichiers et permet de mutualiser et coordonner les développements et même de résoudre certains conflits en cas de modifications simultanées. Le schéma temporel qui suit montre un cas concret d'utilisation de SVN entre plusieurs utilisateurs travaillant sur le même arbre de sources. Côté client on peut utiliser l'outil en ligne de commande svn pour récupérer une copie (svn checkout), mettre à jour sa copie locale (svn update) ou propager les modifications locales vers le serveur (svn commit). On peut aussi ajouter des fichiers (svn add), les effacer (svn delete), les renommer/changer de place (svn rename) ou encore voir les la liste des modifications apportées localement mais non «commitées» (svn status) ou les modifications disponibles sur le serveur mais non ramenées par svn update (svn status -u). On peut aussi utiliser un client graphique gratuit comme SmartSVN (écrit en Java) pour plus de simplicité. Il est notamment recommandé en cas de conflits après une commande update car son outil graphique de gestion des différences entre la version serveur et la version modifiée localement est vraiment très puissant. 18 / 20

19 Illustration 19: Exemples de modifications gérées avec SVN Illustration 20: SmartSVN: importation d'un repository SVN 19 / 20

20 Illustration 21: SmartSVN: commandes principales 20 / 20