1. 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 ;)

2. 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 ?)

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 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 ;)

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 : 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 ;)

5. 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)

6. 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…)

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

8. 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 …

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

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

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

12. 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) …

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

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

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

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

17. 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 …

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

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

20. 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/

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

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épendance Eventuellement 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 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) …

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 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 …

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

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

29. 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 …

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)  Facile Publier myphingtool en Open Source Ne pas publier les devs spécifiques Présenter MyPhingTool au Forum PHP 2010 (Paris)

31. Merci !des questions ?