20100221 my phingtool - blog

Capitaliser, (S’)Améliorer et Rationnaliserles développements PHP en interne
Olivier Hoareau – Février 2010
Merci de l’effort que vous fournirez si vous lisez ce document en entier ;)

Quelques explications préalables (1/3)
Ce document a été écrit pour un client et anonymisé pour vous
Je développe actuellement un outil pour ce client grand compte qui doit gérer une multitude de projet de développement PHP, leur maintenance, la capitalisation et réutilisation du code
De nombreux concepts présentés ici ont déjà été implémenté dans certains outils connus (Symfony, Zend Framework, RoR…), d’autres sont issus de mes retours d’expériences, dont je remercie les auteurs
L’outil présenté existe (pas encore toutes ses fonctionnalités), est en cours de développement et n’est pas un mythe ;)
L’objectif de cet outils n’est absolument pas d’être un nième framework, mais un outil pour cadrer les pratiques de développement tout en laissant la possibilité d’utiliser d’autres frameworks (meta-framework ?)

Si des personnes sont intéressés par ce type d’outils, des contributions open source sont éventuellement envisageablesEnvoyer un email à olivier A T phppro D O T fr
Je mets à disposition ce document de présentation principalement pour avoir vos critiques (constructives idéalement ;)) vos retours d’expériences sur les sujets cités et vos questions
Les destinataires de ce document sont des internes (de ce client) qui gère les pratiques de développement en transverse et outillages associés, notamment pour PHP (mais pas que)*
Il est possible que beaucoup de points ne soient pas compréhensibles (car trop contextuels), je m’en excuse par avance et m’engage à vous donner toutes les explications aux questions que vous vous poseriez ;)
*lorsque dans le document je m’adresse à quelqu’un c’est donc à ces destinataires initiaux ;)

L’outil, basé sur phing (http://phing.info) , utilise massivement les task standard (Phing >= 2.4.0) suivantes :
Taskdef
Import (pour le fractionnement et la réutilisation des targets)
Property
Phingcall
PropertyPrompt
La génération d’arborescence projet est basé sur une technique très simple :
Stocker un « modèle » d’arborescence avec des paramètres dans les fichiers ET dans les noms de fichiers/répertoires (%{nomVariable}), les variables étant ni plus ni moins que les propriétés disponibles dans le fichier de phing (build.xml / build.properties). Un semble preg_match_all et str_replace suffit pour générer une arborescence à partir du modèle et en ayant remplacer les variables dans le contenu et le nom des fichiers
Il est possible d’utiliser des fonctions pour formatter le texte de remplacement des variable
%{strtolower:name} / %{realpath:home.dir} / …
*lorsque dans le document je m’adresse à quelqu’un c’est donc à ces destinataires initiaux ;)

Constats
PHP est utilisé chez nous (i.e. moi le client)
Plusieurs projets en interne sont motorisés par PHP
Il existe différentes « typologies » de projet PHP (dév spécifique, appli web Zend Framework, appli web Symfony, appli Drupal…)
Les règles de développement sont à unifier
Nous ne sommes pas dans une logique de réutilisation de code déjà développé par nos soins (voir en externe)
Les documents ne sont pas lus par tout le monde
Les équipes projets ont du mal à venir chercher l’info (i.e. dans les cellules d’architecture ou de compétences transverses)

Objectifs
Instancier un projet de qualité professionnelle en quelques minutes sans connaître toutes les bonnes pratiques
Rationnaliser l’arborescence du code
Proposer des fonctionnalités d’intégration continueunifiées et complètes à tous les projets PHP (ne nécessitant pas des heures de configuration sur les outils comme Hudson, PHPUnderControl…)
Proposer un mécanisme de publication et de réutilisation de code en interne (ou externe) simple à l’emploi, standard et compatible avec nos contraintes de déploiement (qui peuvent être très spécifique…)

Une solution possible :
Utiliser Phing (Open Source)
Savoir prendre en compte différentes arbo
Être Compatible Windows / Linux
Être Compatible Poste Bureautique / Serveur
Être Compatible PEAR (et channel PEAR)
Être Extensible et évolutif
Être 100 % PHP
Nom de code: MyPhingTool*
* Ce n’est pas le vrai nom de l’outil…

MyPhingTool: Principe
Centraliser / Maintenir les bonnes pratiques
Installer facilement avec PEAR
Proposer un outil ligne de commande
Déployer simplement tous les outils du dév.
Même outil pour le développeur et la Plateforme d’Intégration Continue (PIC)
Générer une arbo projet en qq secondes
…

Installation
$ pearchannel-discoverpear.<myclient>.fr
$ pear upgrade --alldepsmyclient/myphingtool
$ myphingtool –v
myphingtool v0.0.6, 2010-02-20 16:21:27
Chargement de la nature: myphingtool_nature_default v0.0.2 by Olivier Hoareau (released on 2010-02-21 15:03:05)
Phing 2.4.0

Génération d’un projet
$ mkdir projet1
$ cd projet1
$ myphingtoolgenerate-project
Name: project1
Nature: zend-framework
Naturemodèle de projet prêt à l’emploi

Exemple d’arbo générée
IDE (Eclipse/Netbeans…)-ready

Fonctionnalités embarquable
Arborescence rationnalisée
Gestion des dépendances avec code capitalisé
Paramétrage Apache
Déploiement automatisé sur les serveurs (fichiers + bdd)
Déploiement outillage sur le poste du développeur
Génération de rapports qualité (T.U, Coverage…)
Vérification du respect des conventions de codage
Intégration de tout les outils qualité
Packaging compatible socle technique <client-name-here>
Projet compatible Eclipse (ou autre IDE)
Audit d’un code externe (sous réserve de compatibilité d’arbo)
…

Le fichier myphingtool.ini
Format texte type « ini » (simple)
Minimal
Précise la « nature » du projet (généré)
Donne accès à des commandes phing spécifiques à la nature
Permet à tout moment de changer de nature (si l’arbo est compatible)
myphingtool.ini
nature=zend-framework

Lister les commandes disponibles
$ myphingtool -l
Compatible phing
Liste des commandes disponibles variable en fonction de la nature du projet

Les commandes* qui seront disponibles
help
tests-unit
tests-unit-with-coverage
checks-syntax
checks-conventions
packages-pear
Publishes-pear-package
generates-doc
builds-on-commit
builds-nightly
packages
deploys(-Dtarget=dev|int|test|preprod|prod)
publishes-metrics
cleans
installs-dependencies
adds-dependency
removes-dependency
upgrades-dependency
lists-dependencies
…
* Target Phing
Compatible phing
100% disponible sur le poste de dev + sur la PIC

Pré-requis
PHP 5.2.0+
PEAR 1.9.0+
Accès internet (avec proxy éventuellement)
Les dépendances sont vérifiées à l’installation et sont « tirées » (sauf pour la version de PHP)
Il n’y a donc qu’un seul outil à installer en plus de PHP et PEAR (il tire toutes les autres dépendances)
Il est envisageable d’installer l’IDE (Eclipse…) et tout autre outil en dehors de PHP (donc Apache, MySQL…) avec cet outil, mais ce n’est pas prévu dans les développement en cours

Qui peut / doit utiliser MyPhingTool ?
Les développeurs  gagner du temps
Les chefs de projet  contrôler / qualifier
La PIC  contrôle automatisé et déploiement
Les prestataires consultants  audit de code
…

Compétences nécessaires pour la maintenance
PHP 5+
PEAR
Phing
PHPUnit
Outillage qualité (phploc, phpcpd…)
Connaissances des bonnes pratiques de développement PHP (apprentissage possible)
…
Il n’est pas nécessaire qu’une seule personne connaisse tout, la compétence peut être diffusé, mais doit être complète

Démarche de capitalisation du code
Identifier le code à capitaliser
Générer un projet de nature « package-pear »
Intégrer le code récupéré / développé dans l’arbo vierge
Nettoyer le code pour qu’il soit propre
Réaliser les éventuels tests unitaires
Packager le code (« myphingtool packages-pear »)
Publier le code sur le channel PEAR interne (ou externe)
Communiquer sur le feeddev (si pas automatique)
Objectif: une multitude de « petits » paquets, plutôt que quelques grosses librairies

Comment créer un « paquet » capitalisé
$ mkdir lib-paquet1
$ cd lib-paquet1
$ myphingtoolgenerate-project –Dname=lib-paquet1 –Dnature=package-pear
Puis copier / nettoyer / génériciser votre code dans le répertoire sources/

Comment publier du code en tant que code capitalisé ?
Mettre à jour la version dans le fichier configs/phing/build.properties
$ myphingtool packages-pear
$ myphingtoolpublishes-pear-package

Comment utiliser du code capitalisé dans un projet ?
$ myphingtooladds-dependency
Type:pear
Name: lib-paquet1
Channel:pear.<myclient>.fr
Version: 0.0.1
Required: true
$ myphingtoolinstalls-dependencies
Les différentes dépendances sont alors téléchargées et installées via PEAR dans le répertoire dependencies/library/ du projet (qui n’est pas subversionné !), ce répertoire étant ajouté automatiquement dans l’includepath

Et les projets utilisant des frameworks ?
Comme :
Zend Framework, Symfony, Drupal, Joomla, Magento, …
Technique à mettre en œuvre :
« Pear-iser » le framework (générer un projet de nature package-pear et copier le code PHP dans sources/)
Publier le paquet PEAR du framework sur le channel interne (ou externe)
Utiliser MyPhingTool pour générer un projet vierge et ajouter la dépendance
Eventuellement créer une « nature » dédié à cette typologie de projet (<= 0,5j de charge)

Je suis chef de projet de dev PHP, pourquoi je choisirai cette solution ?
Une piste pour éviter de dépenser de l’énergie / charge sur des développements déjà réalisé en interne (ou ailleurs)
Suivre l’évolution du niveau de qualité du projet au fil de l’eau (je recevrais un email tous les matins avec des métriques qualité, voir des graphiques), je n’aurais pas besoin d’aller voir un outil même en ligne
Mes développeurs n’ont pas forcément besoin de connaître tous les outils (notamment de qualité)
Je pourrai avec mes développeurs augmenter progressivement le niveau de qualité attendu (enrichissement des règles de codage graduel)
J’aurai du support technique sur les sujets transverses (outillage, intégration continue, bonnes pratiques)
Mes développeurs ne feront pas n’importe quoi
Je pourrais auditer régulièrement *moi-même* l’application (point de contrôle générique)
…

Je suis chef de projet, qu’est ce que ca me coûte pour la mise en place?
0€
Installer PHP et l’outil (quelques minutes)
Générer un projet à partir d’un modèle (quelques secondes)
Présenter le socle et les pratiques à mon équipe (1-2 heures avec un coach technique)*
* Chez ce client, une cellule transverse pourra potentiellementmettre à dispo un coach technique comme moi pour les projets

Point de situation
Proof Of Concept réalisé et concluante
Développement à 60% mais déjà réalisé de façon éparpillée pour différents clients (à nettoyer, génériciser…)
Reste à faire:
Committer tout ça sur un SVN (a priori celui du client, peut être une partie OSS)
Créer un espace wiki (confluence)
Créer un espace bugtracker (Jira)
Saisir la TODO List dans le bugtracker
Développement de certaines « target »
Installation channel PEAR interne
Installation / Paramétrage PIC
Packaging des dépendances standard (ZF, ExtJS…)
Formation Equipe Capitalisation
Documentation étendue
Créer un feed RSS à destination de l’ensemble des développeurs PHP interne
…

Comment s’organiser ?
Être « agile »
Laisser la possibilité à n’importe qui (interne ou prestataire) de contribuer
S’engager à terminer une tâche lorsque l’on se l’est attribué (via bugtracker par exemple) et ce dans le timing de l’itération
Créer une liste de diffusion pour les personnes intéressés pour « maintenir » et animer la cellule capitalisation
Utiliser le bugtracker pour gérer la Todo-list
Nommer un Product-Owner (permanent) responsable de la « roadmap » des « services » fournis par la cellule transverse
Rentrer dans une démarche itérative (itération de 2 semaines)
Faire des « electronic-standup-meeting » (eSum) en envoyant un email chaque jour ou l’on travail sur le sujet à la liste de diffusion

Comment vous pouvez aider ?
En béta-testant sur vos projets
En dépilant les tâches dans bugtracker
En identifiant les projets candidats / Faisant la promo
En faisant des remarques / propositions d’amélioration
En participant à une présentation technique détaillée (par mes soins, à planifier)
En identifiant et recensant le code existant à capitaliser
En créant ensemble une cellule d’aide aux projets PHP fournissant du support sur cet outil et les pratiques associées

Comment je peux vous aider ?
En vous faisant monter en compétences sur ces sujets
En planifiant avec vous la mise en place
En traitant les tâches de développement non prises
En suivant les itérations avec le productowner
En étant en support technique « à la demande » (best-effort)
En aidant les projets à démarrer avec MyPhingTool et les pratiques associées
En vous aidant à « capitaliser » du code identifié
En animant avec vous la cellule PHP (mailing list)
En formant vos prestataires au développement pro
…

Pour aller plus loin…
Proposer des targetphing complémentaire comme par exemple « myphingtoolgenerates-audit-report »
Capitaliser le maximum de code développé sur le Projet XXX et le Projet YYYY, et … ?
Mettre en place une page web de génération de projet (formulaire nom, nature et téléchargement d’un zip tout prêt)  Facile
Publier myphingtool en Open Source
Ne pas publier les devs spécifiques
Présenter MyPhingTool au Forum PHP 2010 (Paris)

Merci !des questions ?

http://blog.phppro.fr	138
http://www.bonbudget.com	21
http://www.slideshare.net	9
file://	1
http://www.netvibes.com	1
http://www.lmodules.com	1
http://192.168.19.1	1

20100221 my phingtool - blog

by PHPPRO

Accessibility

Upload Details

Usage Rights

7 Embeds 172

Statistics