Your SlideShare is downloading. ×
0
20100221   my phingtool - blog
20100221   my phingtool - blog
20100221   my phingtool - blog
20100221   my phingtool - blog
20100221   my phingtool - blog
20100221   my phingtool - blog
20100221   my phingtool - blog
20100221   my phingtool - blog
20100221   my phingtool - blog
20100221   my phingtool - blog
20100221   my phingtool - blog
20100221   my phingtool - blog
20100221   my phingtool - blog
20100221   my phingtool - blog
20100221   my phingtool - blog
20100221   my phingtool - blog
20100221   my phingtool - blog
20100221   my phingtool - blog
20100221   my phingtool - blog
20100221   my phingtool - blog
20100221   my phingtool - blog
20100221   my phingtool - blog
20100221   my phingtool - blog
20100221   my phingtool - blog
20100221   my phingtool - blog
20100221   my phingtool - blog
20100221   my phingtool - blog
20100221   my phingtool - blog
20100221   my phingtool - blog
20100221   my phingtool - blog
20100221   my phingtool - blog
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

20100221 my phingtool - blog

1,765

Published on

0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,765
On Slideshare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
0
Comments
0
Likes
2
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

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

×