Ok

En poursuivant votre navigation sur ce site, vous acceptez l'utilisation de cookies. Ces derniers assurent le bon fonctionnement de nos services. En savoir plus.

Outils - Page 2

  • Pourquoi un framework php open source ?

    symfony.jpg

    Je poursuis ma note d'hier avec un cas concret. Faut-il choisir un framework open source ou développer en interne ?

    Choisir un framework se fait souvent dès le début du projet. Quels sont les critère à retenir ?

    Le temps

    La formation à un framework est souvent longue car il faut que chaque développeur comprenne la physionomie du framework en question. Mais une fois acquise, ce sera un gain car développer et maintenir un framework maison, c'est un gouffre qu'il faut savoir rentabiliser.

    zend-framework.png

    Les fonctionnalités

    Aujourd'hui, les framework PHP embarquent des outils de type tests unitaires, ... c'est un gain de ne pas avoir à tout refaire. Cela dit avoir le choix des armes quand on est expérimenté, cela est un avantage.

    Une expertise nécessaire

    Qu'il 'agisse d'un framework maison ou open source, il est nécessaire de dégager un expert de celui ci qui garantira le développement dans les règles de l'art. Cependant, pour garantir le niveau, des sociétés de conseil autour des framework php sauront apporter un regard extérieur sur les développements et donc une valeur ajoutée : ils peuvent être cette expertise en attendant qu'un "guru" dans l'équipe émerge.

    Les ressources humaines

    Il est plus facile de trouver un développeur qui a déjà codé sur un outil open source qu'un projet maison !

     

    Ma conclusion est plutôt favorable au framework PHP pour une équipe qui n'a pas formcément une expérience et une formation d'architecte logicielle. L'utilisation de nombreux plugin disponible me semble un plus mais il ne faut pas oublier un principe essentiel en développement : détourner un outil ou un soft qui n'est pas prévu pour être utilisé comme on a l'intention de le faire répond toujours de manière bancale au besoin. Pour être claire, on n'utilise pas un marteau pour faire office de tourne-vis. Ne riez pas, c'est tellement courrant !

  • Un ami nommé Hudson

    Comment dire ? Je suis litéralement tombé sous le charme de Hudson. Bon je sais, je m'emporte, mais en 2 heures, je suis arrivé à ce que je voulais !

    Nous avons un outils de versioning pour faire nos branches, patch, .... Pour le déployement en préproduction ou production, nous utilisons des scripts bash (via rsync). Nous avons des tests unitaires à jouer mais ils étaient joués quand quelqu'un y pensais. Nous avons un bug tracker pour rapporté les bugs des développeurs...

    Nous avions pleins d'outils mais ils se sentaient seuls, limite ils faisaient de la dépression ;). Alors nous avons décider de les réunir autour d'un superviseur. Je préfère ce terme à "outil d'intégration continu" car c'est de cela qu'il s'agit. En fait derière Hudson, il n'y a rien, c'est juste un outil qui réuni tous les autres et qui permet d'avoir une vue consolidée de tous les autres.

    hudson.jpg

    Nous débutons un projet PHP, qui tourne avec le framework Symfony. Alors j'en ai profité pour installer Hudson. Je vous avoue que la première fois que j'ai installé Hudson, je me suis démandé à quoi ça servait tellement c'était vide. Et, j'ai installé quelques plugins et en moins de deux heures, j'ai configuré un environnement qui check le style du code PHP, déploye une version en préproduction en utilisant lançant mes scripts habituels (script + nouvelle base de données) et jeu de tests unitaires via le framework de test de symfony. Si un test casse toute l'équipe reçois un mail (avec le reporting du test qui a cassé). Les tâches s'enchaînent sur le succès des uns et des autres.

    En peu de temps on peut installer un environnement pour commencer à s'aguerrir à l'intégration continue. Me consernant, je me pose encore des questions d'organisation :

    • Comment organiser les tâches ?
    • Ne vaut-il mieux pas découper au niveau de Hudson chaque taches élémentaires et les enchaîné ?
    • Est-il plutôt préférable de regrouper plusieurs actions (déployeemnt et jeu de test) au sein d'un "build" (tache hudson) ?
    • L'intégration de Phing est-elle nécessaire car l'exécution de script bash est possible directement via Hudson ?

    L'usage me donnera les réponses ?

  • Environnement de développement

    En route vers l'industrialisation d'un projet web : l'environnement de développement

    L'environnement de développement LAMP nécessite forcément un outils  de versioning, et à mon sens, c'est la clef de voûte du projet. Si celui-ci est absent ou mal organisé, le projet aura du mal à être automatiser, car il est si simple d'éditer un fichier sur un serveur pour corriger rapido un bug, n'est-ce pas ?

    Les outils que j'ai l'habitude proscrire pour développer, en environnement de développement :

    • pusher des fichiers en ftp sur un serveur LAMP
    • utiliser winscp pour la même chose

    Ce que je préfère :

    • un serveur samba + LAMP ou chaque développeur pourra éditer ses fichiers. De cette manière on gagne du temps. Vous rendez-vous compte du temps perdu à pusher des fichier
    • un serveur SVN ou chacun "checkout" les projets
    • putty pour les configuration apache de chacun. Quelques liens symboliques font souvent l'affaire !

    Certain vont rigoler, mais j'ai souvent vu la solution 1. La deuxième, plus élégante, nécessite que l'on prenne du temps pour organiser cela. Au fond, je sais pourquoi on arrive à la solution. Au début, l'installation 2 est nickel et puis, le temps passe, le serveur devient de plus en plus "crade" à force de mettre des applicatifs et puis il y a un bout qui lâche, ou la personne qui a mis en place ce serveur est parti, ou on installe un autre serveur de dev car le premier est plein, et, et, et ... il faut bien se débrouiller, alors, on fait du ftp !

    Pour la gestion des branches, c'est la même chose. J'ai remarque que tout le monde s'en sors pour installer cvs ou svn, mais beaucoup ne s'en servent pas avec efficacité. Je vais donner ici, une méthode simple pour commencer sous svn :

    • On crée un projet avec trois répertoires : trunk, branches et tags
    • Chaque utilisateur développe dans trunk
    • Une fois les développements finis ou que l'on veut montrer le site en production, faire un svn copy vers un nouveau répertoire branche
      • ex : svn copy http://svn.localhost/mon_projet/trunk http://svn.localhost/mon_projet/branches/2009-08-31/
      • cela va recopier et figer ce que vous avez dans trunk
      • c'est cette version qu'il faudra envoyer sur un serveur de production
    • Pour faire évoluer un fichier :
      • faire une comparaison entre les répertoires trunk et branches/date/ et passer les modification commité dans trunk
    • Si vous avez trop de modification recréer un branche.

    Cette méthode, convient pour un faible nombre de développeurs, et garanti relativement bien les non-régressions de code. Utiliser Eclipse sous windows permet d'avoir les diiférence de manière visuelle. En mettant en place un script de déployement de la branche d'un serveur de dev vers vos serveurs de production, vous garantirez qu'ils sont tous à jour avec la même version (cas des serveurs load balancés). Vous pouvez déployer en locale votre branche ou sur un serveur de préproduction, ainsi faire une recette fonctionnelle avant même de modifier vos fichiers.

    Cette configuration de vos projets sous svn est très légère, on pourrais aller plus loin, mais pour commencer, elle apportera un peu de rigueur dans les déployements. Ce sera déjà un progrès !

  • Mon kit kanban

    C'est vendredi alors c'est un peu récréation.

    Plutôt que de vous détailler l'efficacité de la méthode kaban, dont je n'ai pas encore l'expérience pour faire un retour fin, je vais détailler ici ce que j'ai retenu pour mon tableau de Kanban.

    kanban-schema.jpg

    Pour votre atelier bricolage entre collègues de bonne volonté, il vous faut :

    • Une bombe de colle repositionnable
    • Un rouleau de papier kraft prévu pour l'emballage
    • Des post-it de différentes couleurs
    • Un rouleau de scotch crèpé (que l'on utilise pour faire de la peinture ou des dessin pour les architectes)
    • Des fluos
    • Des vignettes autocollantes

    Ce matériel se trouve facilement sur les catalogues de fourniture de bureau.

    Pour les étiquettes, vous trouverez dans le zip le kit nécessaire.

    Et voilà le travail après :

    • matérialisation des colonnes avec le scotch
    • enduction de colle
    • mise en place des étiquette de titre et post-it
    kanban.jpg
    L'idée est de mettre toutes les tâches à faire dans la colonne de gauche. Comme l'itération commence la semaine prochaine, les post-it roses indiquent des points à soulever par l'équipe produit (maquette, liste des champs d'un formulaire, ...). En cours de semaine nous allons déplacer les post-it. Le tableau représente le workflow. Il est assez difficile de savoir jusqu'à quel niveau il faut découper les tâches. L'expérience nous le dira. Nous ferons les ammélioration dans les semaines à venir.

    Notre parcourt de trainning est prêt. Nous avons retenu volontaire peu de vignettes avec un premier sprint court. Il s'agit d'un démarage de projet où il faut aussi règler les scripts de mise en production, les détails de versionning, ...

    Pièce jointe : le kit Kanban et ses vignettes à découper à télécharger (zip) kanban.zip.