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

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