Le document présente le développement d'un outil interne, appelé myphingtool, destiné à rationaliser et capitaliser les projets de développement PHP au sein d'une entreprise. Cet outil, basé sur Phing, vise à unifier les pratiques de développement, faciliter l'intégration continue et permettre la réutilisation de code, tout en étant compatible avec différents environnements. À travers ce projet, l'auteur sollicite des retours constructifs et des contributions open source de la part des destinataires pour améliorer les outils et pratiques existants.

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

2. Quelques explications préalables (1/3)Ce document a été écrit pour un client et anonymisé pour vousJe 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 codeDe 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 auteursL’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 ?)

3. Quelques explications préalables (2/3)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 frJe 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 questionsLes 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 ;)

4. Quelques explications préalables (3/3)L’outil, basé sur phing (http://phing.info) , utilise massivement les task standard (Phing >= 2.4.0) suivantes :TaskdefImport (pour le fractionnement et la réutilisation des targets)PropertyPhingcallPropertyPromptLa 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 fichiersIl 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 ;)

5. ConstatsPHP est utilisé chez nous (i.e. moi le client)Plusieurs projets en interne sont motorisés par PHPIl 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 à unifierNous 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 mondeLes équipes projets ont du mal à venir chercher l’info (i.e. dans les cellules d’architecture ou de compétences transverses)

6. ObjectifsInstancier un projet de qualité professionnelle en quelques minutes sans connaître toutes les bonnes pratiquesRationnaliser l’arborescence du codeProposer 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…)

7. 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 % PHPNom de code: MyPhingTool** Ce n’est pas le vrai nom de l’outil…

8. MyPhingTool: PrincipeCentraliser / Maintenir les bonnes pratiquesInstaller facilement avec PEARProposer un outil ligne de commandeDé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…

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

10. Génération d’un projet$ mkdir projet1$ cd projet1$ myphingtoolgenerate-projectName: project1Nature: zend-frameworkNaturemodèle de projet prêt à l’emploi

11. Exemple d’arbo généréeIDE (Eclipse/Netbeans…)-ready

12. Fonctionnalités embarquableArborescence rationnaliséeGestion des dépendances avec code capitaliséParamétrage ApacheDéploiement automatisé sur les serveurs (fichiers + bdd)Déploiement outillage sur le poste du développeurGénération de rapports qualité (T.U, Coverage…)Vérification du respect des conventions de codageInté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)…

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

14. Lister les commandes disponibles$ myphingtool -lCompatible phingListe des commandes disponibles variable en fonction de la nature du projet

15. Les commandes* qui seront disponibleshelptests-unittests-unit-with-coveragechecks-syntaxchecks-conventionspackages-pearPublishes-pear-packagegenerates-docbuilds-on-commitbuilds-nightlypackagesdeploys(-Dtarget=dev|int|test|preprod|prod)publishes-metricscleansinstalls-dependenciesadds-dependencyremoves-dependencyupgrades-dependencylists-dependencies…* Target PhingCompatible phing100% disponible sur le poste de dev + sur la PIC

16. Pré-requisPHP 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

17. Qui peut / doit utiliser MyPhingTool ?Les développeurs  gagner du tempsLes chefs de projet  contrôler / qualifierLa PIC  contrôle automatisé et déploiementLes prestataires consultants  audit de code…

18. Compétences nécessaires pour la maintenancePHP 5+PEARPhingPHPUnitOutillage 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

19. Démarche de capitalisation du codeIdentifier le code à capitaliserGénérer un projet de nature « package-pear »Intégrer le code récupéré / développé dans l’arbo viergeNettoyer le code pour qu’il soit propreRéaliser les éventuels tests unitairesPackager 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

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

21. 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

22. Comment utiliser du code capitalisé dans un projet ?$ myphingtooladds-dependencyType:pearName: lib-paquet1Channel:pear.<myclient>.frVersion: 0.0.1Required: true$ myphingtoolinstalls-dependenciesLes 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

23. 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épendanceEventuellement créer une « nature » dédié à cette typologie de projet (<= 0,5j de charge)

24. 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 ligneMes 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 quoiJe pourrais auditer régulièrement *moi-même* l’application (point de contrôle générique)…

25. 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

26. Point de situationProof Of Concept réalisé et concluanteDé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 bugtrackerDéveloppement de certaines « target »Installation channel PEAR interneInstallation / Paramétrage PICPackaging des dépendances standard (ZF, ExtJS…)Formation Equipe CapitalisationDocumentation étendueCréer un feed RSS à destination de l’ensemble des développeurs PHP interne…

27. Comment s’organiser ?Être « agile »Laisser la possibilité à n’importe qui (interne ou prestataire) de contribuerS’engager à terminer une tâche lorsque l’on se l’est attribué (via bugtracker par exemple) et ce dans le timing de l’itérationCréer une liste de diffusion pour les personnes intéressés pour « maintenir » et animer la cellule capitalisationUtiliser le bugtracker pour gérer la Todo-listNommer un Product-Owner (permanent) responsable de la « roadmap » des « services » fournis par la cellule transverseRentrer 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

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

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

30. 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)  FacilePublier myphingtool en Open SourceNe pas publier les devs spécifiquesPrésenter MyPhingTool au Forum PHP 2010 (Paris)

31. Merci !des questions ?