|
Industrialisation des développements web : cas du langage php( Télécharger le fichier original )par Jean-Luc NTA à NWAMEKANG Institut Supérieur de Technologie et du Design Industrielle - European Master of Computer Science 2010 |
· Attributs de la tâche
Tableau 3 : liste des attributs de la tâche DbDeploy · DéploiementDans l'architecture du projet en annexe (Annexe 2), le dossier «db« contient les fichiers sql, le dossier «deploy« contient nos scripts de build, le dossier «library« contient le code de l'application et le dossier «public« contiendra les scripts et fichiers accessibles directement à partir du web. Le fichier de configuration (propriétés) qui va permettre d'exécuter la migration de la BD est formaté sous la forme : clé=valeur et édité avec un quelconque éditeur de texte puis enregistré sous : «deploy/build.properties«.
Figure 6 : Fichier Build.properties Ensuite la tâche de migration à insérer dans notre construction est : Figure 7 : Description de la tâche dbdeploy de phing
ETUDE D'UNE SOLUTION D'INDUSTRIALISATION Chapitre IV. L'ENVIRONNEMENT DE TRAVAIL IV.1 Configuration matérielle et logicielle · Matériel Ringo SA est dote d'un Datacenter serveur constitue de 2 blade center IBM type H, dont 28 lames. Chaque lame ayant les caractéristiques suivantes : - 2 Processeurs QuadCore, 2.5 Ghz cpu - 8 Go de Ram - 2 cartes réseaux broadcom - 2 cartes HBA D'une baie de disque constitue d'un contrôleur DS4700 et d'une enclosure EXP810 d'une capacité totale de 8 TB. Le blade center est connecté à la baie des disques via la technologie san au travers des modules FC connectés. · Logicielle Ringo SA a mis en place une infrastructure de virtualisation xen pour l'hébergement des serveurs. Ainsi, sur chaque serveur est installé l'hyperviseur xen sur lesquels sont déployés les pools de ressource et les machines virtuelles elles mêmes. Ringo S.A a donc déployé une infrastructure xen constituée de 3 principaux pools de serveurs : - Le pool production dans lequel sont déployées les machines virtuelle utilisée pour la production. - Le pool test dans lequel sont déployés les machines virtuelles utilises pour les tests. - Le pool corporate dans lequel sont déployés les machines virtuelles pour les corporates. Le but de cette création de pool étant : - La séparation étant de pouvoir délimiter déjà de façon logique la communication entre les différents pools, sauf ci cela est défini implicitement. Un serveur de test ne doit communique pas avec un serveur de production. - La gestion efficace des machines virtuelles dans un pool en permettant les migrations a chaud, le démarrage des machines virtuelle sur l'hôte le plus disponible, ... Dans le cas de notre travail, nous avons bénéficie d'un serveur dans le pool de test d'un serveur debian Lenny. Parmi les différents outils existants et que nous avons explorés, nous avons fait un choix en fonction de l'interopérabilité de chacun, ainsi on utilisera : · Gestionnaire de version : Subversion (gestion de codes sources) · Test Unitaire : PHPUnit · Test IHM : Selenium (Outil de tests de recette pour applications web via navigateur) · Scripts d'automatisation : Phing · Serveur d'intégration : Xinc Chapitre V. Installation et configuration de SVN V.1 Installation du serveur SVN Nous avons installe svn avec le module webDav pour permettre l'accès au dépôt via une interface web. Les commandes d'installation sont les suivantes : - apt-get install subversion - apt-get install libapache2-svn Création du dépôt initial : - svnadmin create -fs-type fsfs /var/depot Nous devons autoriser l'acces au dépôt a apache et aux autres utilisateurs - groupadd subversion - addgroup jeanluc subversion - addgroup Patrick subversion - chown -R www-data :subversion /var/depot - chmod -R 770 /var/dépôt/* Maintenant, nous devons activer le module web pour permettre la connexion au dépôt en http : - a2enmod dav - a2enmod dav_svn Les modules étant actives, nous devons éditer le fichier de configuration pour spécifier l'emplacement du dépôt et la gestion des accès : Le fichier de configuration est : /etc/apache2/mods-available/dav_svn.conf <Location /depot> DAV svn SVNPath /var/dépôt AthzSVNAccessFile /var/access-svn/access_authz AuthType Basic AuthName "Depot svn" AuthUserFile /var/access-svn/access Require valid-user SSLRequireSSL </Location> Puis, tel qu'indiqué dans le fichier dav_svn.conf nous gérons les accès à partir de 2 fichiers : - access pour contrôler les accès au dépôt - access_authz pour contrôler les accès aux répertoires du dépôt pour les utilisateurs étant authentifiés par le fichier access. La création du fichier access se fait via les commandes suivantes : htpassword -c /var/access-svn/access jeanluc htpassword /var/access-svn/access Patrick Ensuite, nous éditons le fichier contrôlant l'accès à des dossiers spécifiques access_authz [/] * = rw .[/siteyaounde] Patrick = rw Jeanluc = r Ici, jean-luc a accès à tout le dépôt en lecture et en écriture sauf au dossier « siteyaounde ». Apres avoir édité ce fichier, nous redémarrons le serveur apache via la commande : /etc/init.d/apache2 restart
La première chose à faire lors de la première utilisation est de créer un nouveau projet. Deux cas de figure peuvent se présenter : ou bien le projet existe déjà au sein d'un dépôt et il s'agit de récupérer ce projet en local pour en faire une copie de travail, ou bien ce projet existe en local et doit être importé au sein du dépôt. Dans notre cas le projet se trouve en local et doit être importé sur le référentiel de code source. Au cas ou il existe plutôt sur le dépôt une seule commande suffit pour effectuer un checkout et récupérer la dernière version des fichiers : il s'agit de la commande svn co. · Import d'un projet déjà existant en local Si le projet n'existe pas dans le dépôt et qu'il faut le créer à partir de fichiers locaux, la commande à utiliser est svn import. Cette opération n'est en théorie effectuée que par la personne chargée de l'administration du dépôt. >> svn import ./projetTest /var/svn/projetTest -m "import initial de Jean-Luc" Chapitre VI. Mise en place du serveur d'intégration Le choix que nous avons porté sur le serveur d'intégration continue Xinc est tout à fait justifié car il correspond à ce qu'il faut pour un projet de développement PHP. Ces caractéristiques sont les suivantes : la plateforme d'exécution est PHP, il s'installe à partir du Framework PHP PEAR, il supporte SVN et PHP (car codé lui-même en PHP), l'interface web est supportée sous Apache. Xinc est un logiciel gratuit distribué sous les termes de la licence LGPL. Pour une liste détaillée des logiciels nécessaires et les bibliothèques, consultez le tableau ci-dessous des dépendances de logiciels : Tableau 4 : Xinc - dépendances logicielles VI.1 Installation du serveur Xinc Xinc peut être installé grace au package PEAR de deux manières: >> pear channel-discover pear.xinc.eu >> pear channel-discover pear.phing.info >> pear channel-discover components.ez.no >> pear install xinc/Xinc OU >> pear channel-discover pear.xinc.eu >> pear channel-discover pear.phing.info >> pear channel-discover components.ez.no >> pear install http://xinc.eu/api/deliverable/get/download/xinc-dev/latest- successful/Xinc-Latest-Dev-2.0.1.tgz Pour que xinc soit prêt à être
exécuter, on doit exécuter un script de
configuration: Ce script permet de configurer les répertoires spéciaux selon les besoins de Xinc ainsi que configurer l'interface Web de Xinc: 1. Répertoire des fichiers de configuration Xinc: /etc/xinc, 2. Répertoire des projets Xinc et des informations de statut: /var/xinc, 3. Répertoire des fichiers journaux Xinc: /var/log, 4. Répertoire du fichier de démarrage/arrêt de Xinc: /etc/init.d, 5. Répertoire d'installation de l'application web de Xinc: /var/www/xinc, 6. Adresse IP de l'application web de Xinc: 127.0.0.1, 7. Port de l'application web de Xinc: 8080. Pour terminer l'installation Xinc. >> sudo ln -s /etc/xinc/www.conf /etc/apache2/sites-enabled/ >> sudo apache2ctl restart - Activer le mode mod-rewrite : ajouter la ligne suivante au fichier httpd.conf LoadModule rewrite_module /usr/lib/apache2/modules/mod_rewrite.so
Ce fichier en question est : etc/xinc/conf.d/xinc.xml (annexe 1) - Pour démarrer xinc exécutez: sudo /etc/init.d/start xinc VI.2 Fichier de configuration .ini Xinc permet de configurer certains paramètres, qui déterminent le comportement de l'interface graphique et / ou de comportement des plugins. Ce qui suit est notre fichier de configuration: [xinc] version = 2.0.1 etc = /etc/xinc etc_conf_d = /etc/xinc/conf.d dir = /var/xinc status_dir = /var/xinc/status project_dir = /var/xinc/projects www_dir = /var/www/xinc www_port = 8080 www_ip = 127.0.0.1 log_dir = /var/log [web] title = " Serveur Xinc" logo = "/images/myServerLogo.png" ohloh = 1 [phing] path = /my/alternative/path/to/phing [svn] path = /my/alternative/path/to/svn VI.3 Interface web d'administration
Figure 8: Tableau de bord du Xinc 2.0 alpha
Figure 9 : détails présentant le statut du build et les builds précédents
Figure 10 : détails du build - Artefacts du navigateur Chapitre V. Paramétrage du système de build L'automatisation des opérations répétitives dans un projet de développement peut être résolue de multiples manières allant du simple script lancé à la main au système d'intégration continue. La plupart des langages ont standardisé leurs outils, make pour C, Ant pour Java... PHP bénéficie lui aussi d'un tel outil : Phing. Phing est un projet Open Source très inspiré de Ant. Le concept est assez simple. Un fichier XML décrit une série d'actions possibles pouvant ou non être dépendantes les unes des autres et une ligne de commande permet de déclencher ces actions. |
|
