Depuis quelques temps j’ai repris mes travaux déjà énoncés symfony rencontre Hudson, Mantis et les autres. J’ai mis à disposition un template générique d’un build.xml pour Phing exclusivement, accessible sur mon Github : jenkins-phing-symfony. Il permet d’analyser son code symfony 1.x avec à peu près tous les outils en vogue du moment.

A ce propos, PHPLoc ne comporte pas de tâche Phing mais Raphael Stolt en a écrit une qui semble fonctionner : phploc-phing.

A noter également qu’il faut passer une variable à ce script pour indiquer le nom du projet:

Plusieurs targets sont disponibles :

• main : Lance tout ce qui suit ;
• clean ;
• pdepend : Lance l’analyse de code statique avec PHP Depend ;
• phpcpd : Lance l’analyse de code dupliqué PHPCPD ;
• phpcs : Lance l’analyse checkstyle avec PHP_CodeSniffer ;
• phpdoc : Lance la génération de la documentation avec phpDocumentor ;
• phploc : Lance l’analyse PHPLoc ;
• phpmd : Lance l’analyse PHP Mess Detector.

D’autre part, j’ai mis à jour mes règles Checkstyle (PHP_CodeSniffer) pour symfony 1.x : phpcs-symfony.

Après exécution sur mes projets, ces règles permettent de bien respecter les standards imposés par symfony 1.x (uniquement).

Voilà pour les nouvelles

Related Posts

• symfony rencontre Hudson, Mantis et les autres
• Faut-il tester… les tests ?
• Symfony live 2011
• Création automatique d’un projet symfony + MySQL + Git et Apache2
• Déploiement automatisé avec Capistrano et Git pour symfony et Diem

Bon, c’était une liste des features de Sf2, les slides suffisent à expliquer ce qui a été dit.

 Introducting Assetics

« If you haven’t optimized frontend, you haven’t optimized. »

Beaucoup d’outils existent pour gérer ses assets : yui compressor, sass, less, jsmin, coffeScript, cssEmbed, sprockets, stylus, pcaker, … Aucun n’est écrit en PHP ⇒ Assetic ! (Viens du mot « asceticism »).

AsseticBundle

Assetic : dump –watch

HTTP Cache

Lire la documentation HTTP (la RFC là, vous savez ).

Deux types de cache existent :

http expiration : cache-control, expires

• expires : utilise les dates spécifiées dans la RFC C1123 ⇒ gmdate()
• cache-control : à utiliser contrairement à expires.
• L’expiration permet d’accroître le nombre de requêtes possible sur son serveur.

http validation : last-modified, etags

• 304 not motified, last-modified/ if-modified-since
• La validation préserve la bande passante !

PHP ajoute un header de ce type dès lors qu’il y a une session :

Proxy cache

Shared cache, client side

Gateway cache

~proxy but server side, CDNs

Varnish

Symfony2 en pièces détachées

• Escaping enlevé de Sf2
• transChoice() permet de gérer la pluralisation

Avis global

Génial, vraiment. J’ai pu rencontré pas mal de gens intéressants. Les conférences étaient toutes sympathiques et le cadre agréable. J’ai vraiment passé deux bonnes journées et je remercie Sensio de m’y avoir invité. Vivement l’année prochaine !

Related Posts

• Symfony live 2011 – Journée 1
• Symfony live 2011

Les conférenciers commencent par bâcher Drupal, en gros ce n’est pas bon sauf pour les utilisateurs finaux.

Ensuite on passe au CMF : Content Management Framework. Qu’est-ce dont ?

• Une boite à outils pour créer son propre CMS.
• Pas un truc qui rassemble tout mais un truc qui s’améliore avec le temps.
• Diem, Apostrophe, Sympal construis sur la même base.

Et le projet Symfony CMF ?

• Environ 100 personnes dans la mailing-list.
• +10 par mois.
• La plupart des décisions clés sont prises sur un forum public.
• Soutenu par des entreprises tels : KnpLas, Theodo, ideato, Liip, OpenThink Labs, …

Au niveau technique, les données d’un CMS ne sont pas très gérables donc utilisation du NoSQL, pas de SGBDR. Certains CMs organisent des données en arbre, on peut utiliser : Graph DBs.

Pour Symfony CMF, on devrait avoir :

• Versionning du contenu
• Gestion fine des accès
• Doctrine PHPCR ODM
• Jackalope (Java)
• Utilisation de PHPCR, une interface qui permet aux devs PHP de garder leurs habitudes (exemple : tableaux associatifs qui n’existe pas en Java). Ainsi, on ne discute pas avec Jackalope.
• PHPCR/JCR ne sera pas utilisé pour tout sauvegarder. Les données « web », les commandes d’un site e-commerce (par exemple) ou ses stocks iront dans un SGBDR. Idem pour l’agrégation, mieux supportée et faite dans un SGBDR.

Adresse du projet : Symfony CMF.

Restful avec symfony et Symfony2

Définition/Explications d’un Web Service :

• Développement d’APIs/Webservices
• Communication inter-langages/inter-logiciels
• Fournisseur : service
• Agent : client
• Deux types : REST ou WS-*

Web services en Symfony 1

• Utilisation du système de routing
• Utilisation d’un serializer qui n’est pas présent dans symfony ou Zend.
• Il existe cependant un Exporter Doctrine.
• En json : json_encode($object->toArray()) ;

Cependant, comment valider les entrées ? La présence du payload ? Hé bien en utilisant les validateurs de symfony.

Abordons la partie sécurité (accès, rythme, fréquence (throtting)) :

• Autentification naïve par preExecute, ajouter un paramètre (une clé d’API par exemple) mais ce n’est pas terrible si quelqu’un trouve cette clé.
• Approche OAuth plus que conseillée.
• Throtting : utiliser Apache : mod_cband

Symfony2, on fait comment ?

Export des routes sf2 dans Apache2 :

Il est conseillé de se servir du FrameworkExtraBundle pour le paramConverter !

En Symfony2, on a le Serializer component :

• normalizer ; CustomNormalizer
• GetSetMethodNormalizer : renvoit un tableau clé/valeur PHP
• Encoder : JsonEncoder, XmlEncoder

Varnish, HttpCache déclenchés avant l’initialisation du framework. Validation du cache :

Il est conseillé d’utiliser le Cache HTTP pour les Web Services pour éviter, par exemple, de parser les annotations Doctrine à chaque requête ! Enfin le supra projet, fil conducteur lors de la présentation : Symfpony

Contributing with Git

A mon sens, la meilleure conférence des deux jours, présentée par @chacon. Déjà, voici quelques liens :

• http://git-scm.com
• http://gitref.org
• http://progit.org

1991-2002 : pas de VCS pour le projet Linux.

Git vs SVN (rapide)

SVN : un log par fichier au premier commit, ensuite un log supplémentaire par modification.

Git : checksum de chaque fichier. Au comimit, enregistre un « manifest » avec les checksums des fichiers ajoutés. Au commit suivant, il recrée un checksum. Au renommage, il change juste le nom du fichier à côté du checksum dans le manifest. A la copie d’un fichier, il rajoute juste le fichier dans le manifest mais. => Liste chaînée de « snapshots » (checksums).

git diff fait un diff avec les snapshots concernés, pas avec tout.

Faire de beaux/bons commits :

• Attention aux espaces (blancs)
• git diff –check : pour vérifier avant de commiter
• git add –patch : commit sélectif
• git-gui
• Git Tower
• git-log –grep=xxx
• short summary of changes

Branches

• créer une branche pour toute nouvelle modification (majeure). Ne pas travailler sur Master.

Repository central

• Premier arrivé, Premier Servi
• git push
• git fetch (d’abord)
• puis : git merge

Merge

• can undo the merge
• more data for analysis later
• easy continuous re-integration

Rebase

• « prettier »
• git pull –rebase : sinon pull fetch et merge
• git merge –no-ff : no fast forward, gives more information

Processus de travail en groupe

• Coder
• git fetch
• git log origin/master ^master
• git rebase origin/master

Mailing List Contributor Workflow

• git checkout my-branch
• git format-patch –m origin/aster ⇒ xxxx.patch (email format patch)
• git send-mail *.patch : configure your mail in ~/.gitconfig

Lorsqu’on reçoit le mail : ** git am xxx.patch

Repo personnel

Requesting a Pull : make your branch up to date ⇒ push to a named branch ⇒ contact the author

• git remote add upstream http://xxx:yyy.git
• git rebase upstream/master
• git push origin my_feature
• git checkout –b my_feature
• commit, commit, …
• git fetch upstream
• git rebase upstream/master
• git request-pull upstream/master origin

Accepting a Pull Request : git remote add scott http://xxx.yyy.git ⇒ git fetch scott ⇒ git merge scott/my_feature

Ou : git pull http://xxx:yyy.git my_feature

Symfony2 : 30 astuces et bonnes pratiques

• Organisation plus libre
• Application : une seule ⇒ système de sécurité permet de cloisonner efficacement
• Pour utiliser plusieurs applications, on peut les nommer App1, App2, … Mais normalement on a besoin que d’une seule app’
• Bundles ⇒ implémentation une fonctionnalité spécifique
• Isoler ses classes métiers : Entity/ ou Business/
• Utiliser ses propres namespaces…
• Virer les bundles inutiles.
• On peut définir des variables d’environnement : SYMFONY__XXX ⇒ Depuis un VHOST Apache2
• Format .ini : pour paramètrage de l’application par un non-technicien.
• Twig : XSS protection en automatique et mode sandbox
• Utiliser le router Apache
• Assets : Assetic

 Surcharge des pages d’erreurs

• Créer un service (écouter core.exception, déclarer le service et créer une nouvelle classe).
• Faire un template : on crée un app/FrameworkBundle/xxx.error.html.twig
• Utiliser un contrôleur qui implémente la méthode showAction():

Attention : les contrôleurs ne doivent pas hériter de la classe Controller du FrameworkBundle. Il ne faut pas créé de dépendances ! (c’est presque inutile). Donc les contrôleurs sont de simples classes PHP, sans dépendances. Il vaut mieux hériter du ContainerAware ou alors utiliser des services en tant que contrôleurs.

Twig

Assets ⇒ utiliser les blocks Twig Existence de macros pour Twig.

Injection de dépendances

• classes utilisables sans Container
• utiliser le format XML
• A utiliser pour des objets qui ont une portée globale ou pour des objets « uniques ».
• Ne pas utiliser l’injecteur pour des objets métiers.
• Ne pas injecter le container dans les objets (lol) : injecter le service nécessaire !

Sécurité

• déporter la configuration
• spliter la configuration et l’importer

Profiler

• utilisable en production

• Génère un fichier.
• Importer le dump dans le profiler.
• Utiliser les annotations

FrameworkExtraBundle

• configuration du routing
• configuration des méthodes http
• template à utiliser
• cache http
• convertir des paramètres de requête

 Performances

• autoloading : compile les classes, attention à ne pas trop charger de classes
• cache warmer : préparation du cache
• pré-compilation du template, DI, routing, autoloading
• On peut ajouter nos propres services.

Vérifier la configuration Doctrine

RabbitMQ

Why Messaging ?

The user

Upload picture, don’t want to wait till the images resizes. Notify user friends when she uploads a new image.

The sysadmin

Save my bandwith.

 The developer

Call the PHP from Python.

RabbitMQ & AMQP

Advanced Message Queuing Protocol * Interoperability * Open protocol * Binary protocol * AMQP Model : exchanges, message queues, bindings, rules for binding them * AMQP Wire Format : Functional layer, Message flow

 Scénario : batch

Requirements :

• Generate XML
• Distribution over a cluster
• Elasticity
• No code changes

Design : Enquue job -> generate xml -> direct exchnange -> desc queue -> Worker 1/Worker 2/Worker 3

Integration dans Symfony

RabbitMQ Bundle

Symfony2 Forms

Bon là, je n’ai pas pris de notes, ce fût une lecture de la documentation plus ou moins. J’ai tout de même noté deux infos :

• L’astuce Twig pour rendre le reste des éléments d’un formulaire:

• Et le type : « repeated » to repeat twice a field (password)

Voilà pour cette première journée, plutôt longue mais très intéressante.

Related Posts

• Symfony live 2011 – Journée 2
• Symfony live 2011

Voilà en gros tout ce que j’avais à dire dans cet article Pour étoffer un peu, Symfony Live c’est la conférence tendance pour les gens qui aiment [s|S]ymfony, qui aiment PHP (pourquoi pas ?) et qui aiment bien discuter et écouter de bonnes conférences. C’est organisé par Sensio Labs, agence que l’on ne présente plus, ça se déroule les 3 et 4 mars à Paris (Cité Internationale Universitaire) et c’est à peu près tout ce qu’il faut savoir.

Le vendredi soir, il y aura un meetup Github je ne sais trop où, comme d’hab’ je vais essayer de pas me perdre dans Paris (d’ailleurs j’espère que mon stage me permettra également de me repérer un peu dans Paris…). Il y aura des conférences doublées donc comme au Forum PHP, il faudra faire des choix. J’ai fait quelques choix, les voici :

Jeudi

10h30-11h20 : Je ne sais pas…

11h30-12h20 : Restful avec symfony et Symfony2 par deux compères de CleverAge : Xavier Lacot et Damien Alexandre.

13h30-14h20 : Contributing with Git : Reducing the frictions of Open Source collaboration with the Git VCS par Scott Chacon (ce mec travaille chez Github !!)

14h30-15h20 : je ne sais pas.

15h30-16h20 : je ne sais pas non plus.

16h30-17h20 : Leveraging Symfony2 Forms par Bernhard Schussek (histoire de pas galérer sur les forms…)

Vendredi

8h30-9h20 : Symfony2 – from the trenches par Lukas Kahwe Smith et Jonathan Wage (le titre déchirait !)

9h30-10h20 : Introducing Assetic: Asset Management for PHP 5.3 par Kris Wallsmith.

10h30-11h20 : HTTP Cache par dieu Fabien Potencier. (Et là, ce fût le plus gros dilemme…. Je voulais tellement voir cette conférence sur Solr )

11h30-12h20 : Varnish Cache and you par Kristian Lyngstøl.

13h30-14h20 : Symfony2 en pièces détachées ! par Hugo Hamon. La conf’ sur Twig semble sympa mais je pense qu’il y a plus à apprendre de l’ami Hugo.

14h30-15h20 : Doctrine in the Real World par Jonathan Wage (encore !)

15h30-16h20 : Jeux sociaux, Symfony et Cloud Computing par Laurent Letourmy (je les avais zappé lors du Forum PHP, je me rattrape ici).

16h30-17h20 : Iscool Story par Alexandre Rodière et Bertrand Tornil (Weka again).

Voilà, ce planning est susceptible de changer mais certainement pas trop. Je ferai comme d’hab’ un résumé de chaque journée et pour chaque conférence vue.

A demain pour certain

Related Posts

• Symfony live 2011 – Journée 2
• Symfony live 2011 – Journée 1
• Tests unitaires et fonctionnels sur un Bundle en Symfony2
• Symfony, Jenkins & co
• symfony rencontre Hudson, Mantis et les autres

C’est là que les outils que je vais présenter dans cet article interviennent. Aujourd’hui je parlerai de Hudson, Mantis, Phing, Checkstyle, PhpDocumentor, Pdepend et je montrerai l’interconnexion de tout ça sur un projet symfony.

Mantis

Mantis est un bug tracker, c’est-à-dire un rapporteur de défaillances. Il permet de consigner tous les problèmes survenus sur une application, de déclarer des priorités plus ou moins importantes mais surtout d’avoir un réel échange entre le rapporteur (le client) et l’équipe technique (composée de… moi). L’avantage d’avoir ce type d’outil dépasse ce que je viens de dire mais je m’en sers essentiellement pour avoir un endroit adapté où récolter les défaillances de mes applications. Mantis s’occupe d’avertir tous les gens concernés par mail, lorsqu’un bug est ajouté ou résolu par exemple. Ainsi, je ne perds aucun retour client auparavant stocké dans ma boîte mail sous forme de dizaines de mails et lorsque je résous un bug, le rapporteur concerné est prévenu automatiquement.

Nous allons voir pourquoi c’est si intéressant.

Hudson

J’ai déjà parlé d’Hudson, sans vraiment rentrer dans les détails parce que je ne vais pas réécrire ce qui a déjà été publié x fois, mais cette fois-ci je vais rentrer plus dans les détails. Au passage, Hudson est un serveur d’intégration continue.

Pour un projet symfony, je crée un projet freestyle, connecté à Git avec un déclencheur sur tout changement dans le repository distant. J’ajoute ensuite une succession de tâches symfony :

- création du répertoire log/

- suppression de la base de tests SQLite

- création de la base de tests

- tests

Ceci est un projet basique qui me permet d’avoir une intégration continue et une alerte rapide par mail si un problème survient.

Oui mais voilà, ce n’est pas suffisant, on peut mieux faire. J’ai parlé de Mantis juste avant, il serait bien de pouvoir connecter Hudson avec Mantis. C’est justement ce que fait le Mantis Plugin pour Hudson. Ainsi, si je « commit » une modification qui a résolue un bug, exemple :

Le plugin va pouvoir lier ce changement avec la page Mantis du bug et ajouter les informations liées au commit. Dorénavant, lorsque je « commiterai » un fix, le rapporteur sera prévenu de la résolution du bug qu’il aura soumis. Le gain de temps est indéniable.

Configuration Hudson :

Mais on peut (encore) faire mieux d’une autre manière, c’est-à-dire que si la build est un succès, pourquoi ne pas la déployer. Pour avoir un changement, je dois faire un « push » vers le repository distant. Or, on ne « push » pas tous les jours ou du moins, pas derrière chaque commit. Ce serait un peu perdre l’avantage du mode décentralisé de Git. Ainsi, quand je choisis de faire un « push » c’est que j’estime avoir suffisamment modifié mon projet. Ceci m’amène à penser qu’il devient intéressant de le déployer.

Merci à Capistrano (lire ici mon article sur le déploiement d’applis symfony et diem avec Capistrano) et au SSH Plugin d’Hudson. Ce plugin n’est pas des plus parfaits mais il fonctionne. Si la build passe, je lance mon déploiement. Normalement, le déploiement n’échoue pas, si c’était le cas alors : capistrano ferait un rollback sur la dernière version fonctionnelle et les logs Hudson m’indiqueraient le problème. Je peux donc être rassuré de ce côté-là.

Jusqu’à présent, je n’ai parlé que d’automatisation des aspects « après développement » à savoir les feedbacks client et le déploiement. Ce sont les deux points essentiels après réussite des tests. Pour autant, Hudson peut aider l’équipe de développeurs en effectuant une série d’analyses.

Phing : l’Ant des temps modernes (ou pas)

Phing, c’est Ant (utilisé dans le monde Java) version PHP, en quelques mots, un outil d’automatisation de tâches répétitives. Il faut connaître Ant pour comprendre qu’il est génial de disposer d’un outil semblable pour PHP. C’est grâce à cet outil que je génère des rapports d’analyse.

Phing s’installe via PEAR.

Checkstyle : mon code a du style !

Checkstyle est un outil de contrôle de code. Il vérifie le style du code écrit (indentation, commentaires, …). Pour l’utiliser avec PHP, il faut PHP_CodeSniffer (on abrège en phpcs) et le Checkstyle Plugin d’Hudson. Pour l’utiliser avec symfony, on ajoutera le standard symfony : http://github.com/denderello/phpcs-symfony ou si vous utilisez la toute dernière version : http://github.com/willdurand/phpcs-symfony.

Configuration Hudson :

Configuration du build.xml (Phing) :

Et aperçu du résultat :

Pdepend : analyse de code statique

Pdepend, analyseur de code statique, permet de calculer des indices (couplage, instabilité, …) afin de déterminer la qualité du code de la build. Pour cela, il nous faut le Jdepend Plugin d’Hudson et avoir installé pdepend.

Configuration Hudson :

Configuration du build.xml :

DRY ! Analyser les répétitions de code

Don’t Repeat Yourself, adage symfony, on souhaite ici analyser le code dupliqué. Pour cela, on utilise phpcpd (toujours via PEAR) ainsi que le DRY Plugin d’Hudson.

Configuration Hudson :

Configuration du build.xml :

Et aperçu du résultat :

PhpDocumentor : génération de la documentation du projet

PhpDocumentor permet de générer la documentation d’un projet, tout comme Javadoc le ferait. Voici la configuration du build.xml :

On pourrait ajouter le DocLinks Plugin pour Hudson afin de lier la documentation générée à chaque build.

Invoquer Phing

Pour invoquer Phing dans Hudson, on peut soit utiliser le plugin qui gère Phing soit utiliser une commande shell. Je préfère la commande shell pour pouvoir passer des paramètres à mon script.

Couverture de code

Là je vous laisse lire cet article qui explique comment obtenir des rapports de couverture de code symfony dans Hudson.

Conclusion

En plus d’automatiser un certain nombre de tâches, j’obtiens des retours sur mon projet : des retours client grâce à Mantis et des retours sur la qualité de mon travail. Aujourd’hui, des outils pour PHP sont là, il est clair que PHP s’industrialise et grâce à la qualité du framework symfony, il devient intéressant d’adopter les bonnes méthodes et d’utiliser ces outils. PHP, ce n’est plus « Un mini-chat en PHP » par le Site du Zéro.

Il n’est jamais trop tard pour commencer à bien travailler.

Related Posts

• Symfony, Jenkins & co
• Faut-il tester… les tests ?
• Tests unitaires et fonctionnels sur un Bundle en Symfony2
• Symfony live 2011
• Création automatique d’un projet symfony + MySQL + Git et Apache2

Voici donc le script mkSfProject :

Je lance cette commande et en moins d’une minute, j’ai accès à un projet symfony fonctionnel dans mon navigateur. Voilà

Related Posts

• L’erreur « suexec policy violation » avec symfony (chez OVH…)
• Symfony, Jenkins & co
• Symfony live 2011
• symfony rencontre Hudson, Mantis et les autres
• Déploiement automatisé avec Capistrano et Git pour symfony et Diem

La mise en production c’est passer un projet sur le serveur du client pour le rendre accessible aux utilisateurs finaux. Facile ? Non, très souvent les architectures sont différentes et il convient d’utiliser plusieurs environnements. Pour ma part, je dispose de 3 environnements : dev (sur ma machine), test (sur serveur distant) et préprod (sur serveur distant également). Ces environnements me permettent de tester mes projets sur plusieurs OS, plusieurs types de machine et sur deux SGBDR (bases de données) : j’ai pris l’habitude d’effectuer mes tests sous SQLite, j’ai ainsi  deux sons de cloche (en plus de MySQL) me permettant de corriger des étourderies lors de la configuration de la base.

Ok, tout ce speech pourquoi ? Pour pouvoir comprendre mon intérêt à automatiser le process de mise en prod’. En effet, mes trois environnements me garantissent une certaine stabilité de mon application, je n’ai donc pas à jongler avec les serveurs de chacun de mes clients (pas toujours…). Je peux donc déployer (mettre en prod’) mon application presque les yeux fermés. Et ça, ça n’a pas de prix !

Mais je ne joue pas le lanceur de couteaux sans avoir de lames bien aiguisées. J’utilise des outils éprouvés comme Capistrano et Git.

Capistrano est l’outil par excellence pour déployer des applis Rails. Le problème c’est que je ne m’y suis pas encore mis… Mais qu’importe, il déploiera mes applications symfony et Diem. La souplesse de configuration via redéfinition des méthodes permet de déployer à peu près ce que l’on souhaite. De plus, l’interconnexion avec Git se fait sans problème.

Maintenant, courte description :

• Capistrano va cloner votre projet (Git inside) ;
• Capistrano peut compresser votre projet (tar) et l’envoyer à vos X serveurs  ;
• ou Capistrano va demander à X serveurs de récupérer la dernière version de votre projet ;
• Capistrano va lier (symboliquement) la dernière version en tant que version courante ;
• Capistrano va migrer les bases de données (la migration ici, ce n’est pas l’histoire avec les oiseaux… C’est plutôt la mise à jour structurelle de vos bases) ;
• Capistrano va déployer votre appli très rapidement sur autant de serveurs que vous le souhaiter ;
• Capistrano exécute des commandes avant ou après le déploiement, pratique pour un sf cc ;
• Enfin, Capistrano ne fait pas le café (il ne faut pas abuser quand même…)

Intéressant non ? Une fois Capistrano installé (explications ici), on va pouvoir commencer à travailler.

Ce que je fais généralement, je crée un répertoire project_name et je tape la commande :

Ceci me crée un fichier Capfile, un répertoire config/ avec un fichier deploy.rb. C’est ce dernier qui nous intéresse. Le mieux est de partir d’un fichier vide. Pour pouvoir utiliser Git, il faut écrire ceci :

J’indique le chemin de mon dépôt, ici local et la branche (par défaut master). Les paramètres :checkout et :deploy_via ainsi défini permettent de faire un clone complet du projet. Ensuite, quelques paramètres nécessaires :

Maintenant, une petite chose à savoir. Capistrano versionne les déploiements et ça, c’est bon ! Mon déploiement plante, rollback automatique vers la version précédente. Je m’aperçois que j’ai fait une grosse faute d’orthographe, je lance un rollback et l’appli passe en version précédente. Pour cela, Capistrano construit sa propre structure dans le répertoire défini par :deploy_to :

current est le lien symbolique qui pointe toujours vers la version active de l’application. Le répertoire releases/ possède X répertoires correspondant aux différents déploiements passés. Vous l’aurez compris, le lien symbolique current pointe vers l’un de ces répertoires. Le répertoire shared/ quant à lui contient des fichiers partagés par toutes les releases. Exemple : le fichier databases.yml de symfony qui définit les identifiants de connexion à la base de données ou encore le répertoire uploads/ qui contient des données utilisateurs.

On peut désormais personnaliser les actions de déploiement. Pour cela, on va redéfinir les actions de :deploy, qui contient les tâches de déploiement appelées lors de tout déploiement.

<

p style= »text-align: justify; »>

Après déploiement, on va créer fixer les droits, les répertoires de logs et de cache. Ensuite on met à jour la base de données (Doctrine migration). Pour finir on exécute une série de tâches « custom » qui permettent de supprimer les contrôleurs de développement (frontend_dev, backend_dev, …), de recréer les liens symboliques pour les fichiers partagés, de vider le cache symfony ou Diem, …

Voyons la suite de commandes pour symfony :

<

p style= »text-align: justify; »>Et voilà la suite de commandes pour Diem :

<

p style= »text-align: justify; »>Et voilà ! Un simple cap deploy fait tout le reste. Vous pouvez ajouter autant de serveurs que vous le souhaiter et lancer également toutes les commandes qui vous font plaisir.

Si vous avez des problèmes d’hébergement, exemple chez OVH qui ne laisse pas d’accès externe sur leurs serveurs Plan (…), vous pouvez utiliser la configuration suivante qui va archiver votre projet et l’envoyer en SFTP :

Cette configuration est largement inspirée de ces articles :

• http://refineweb.co.uk/2010/01/18/preparing-a-symfony-project-ready-for-deployment-into-production-using-capistrano/
• http://blog.servergrove.com/2010/07/12/symfony-git-capistrano-capifony/
• http://blog.codingspree.net/2008/5/12/deploying-symfony-project-with-capistrano/

Pour terminer, hier je vous parlais d’Hudson, un serveur d’intégration continue. En liant les deux, j’obtiens une automatisation complète de mon « after code« . C’est-à-dire que j’écris mon code comme un barbu (et mes tests). Lorsque j’ai bien commité et que je push mes modifs, Hudson voit ces mises à jour, il va relancer les tests. Si tout passe la build estampillée « success » va être déployée automatiquement par Capistrano.

Et moi dans l’histoire ? Je n’ai rien à faire. Au pire, je suis alerté par mail si un test ne passe pas et si la build ne peut être déployée, Capistrano fera un rollback automatiquement sur sa dernière version stable. Manquerait plus qu’une cafetière USB et une tâche Hudson pour lancer le café et là… utopie !

A noter qu’un projet nommé Capifony a vu le jour depuis quelques temps. C’est un Capistrano réécrit pour gérer nativement les projets symfony, je n’ai pas testé mais cela me semble une excellente option : http://github.com/everzet/capifony. Pour Diem, j’ai vu passé quelque chose dans le Google Groups, à suivre donc.

Vous pouvez, si vous le voulez, utiliser Murder, un projet développé par Twitter pour déployer via Bittorent leurs applications sur tous leurs serveurs. C’est pas une mauvaise idée si vous avez beaucoup de serveurs, leurs temps de déploiements sont assez phénoménales. En parlant de temps, mes temps de déploiements sont de l’ordre de 2 minutes…

C’est tout, pour le moment

Related Posts

• Intégrer un gestionnaire de fichiers dans dmCkEditorPlugin
• Symfony, Jenkins & co
• Symfony live 2011
• symfony rencontre Hudson, Mantis et les autres
• Création automatique d’un projet symfony + MySQL + Git et Apache2

Il y a un presque deux ans maintenant, j’apprenais à écrire des tests unitaires et fonctionnels en Java, à l’aide de JUnit, JMeter, et compagnie. J’ai appris à écrire des scénarios de tests avec un logiciel dont je ne me souviens plus du nom, une alternative gratuite à HP Test Director. On écrit des scénarios de tests, des gens suivent les instructions et fournissent le résultat qu’ils obtiennent. C’est bien gentil tout ça mais je n’ai pas 50 personnes sous la main pour les faire exécuter mes tests et ce n’est pas mon associé qui voudrait suivre mes procédures…

Comme mon boulot consiste à écrire uniquement des sites web, j’ai cherché un outil qui pourrait faire ce boulot à ma place. Il ne m’a pas fallu longtemps pour trouver Selenium, une suite d’outils permettant d’enregistrer un enchaînement d’actions dans le navigateur, de rejouer cet enchaînement autant qu’on le souhaite, sur plusieurs navigateurs, en parallèle (test de « scalabilité« ), …

C’est donc l’outil parfait pour gérer les scénarios fonctionnels. J’enregistre mes tests et je les rejoue. Je vérifie ainsi que mon appli réponds correctement et que je n’ai rien cassé en modifiant une partie du code. Exemple avec symfony, la mise à jour du schema.yml.

D’ailleurs avec symfony, on peut faire des tests fonctionnels et c’est une chose que je ne faisais pas. Pour être franc, je ne faisais pas trop de tests en PHP, enfin si mais pas formellement. Maintenant cette période est terminée. J’adopte une nouvelle approche, l’approche TDD que j’expliciterai plus tard. En symfony, on peut donc faire des tests fonctionnels avec les classes sfTestFunctional et sfBrowser (qui simule un navigateur). Pourquoi utiliser Selenium alors ? Et bien parce que ces tests sont bons mais ne remplacent pas Selenium, par exemple, on ne peut pas tester les appels Ajax. Voici un aperçu d’un test fonctionnel écrit en symfony :

C’est très intuitif, les tests sont formés de « blocs » commençant par with() et terminant par end(). Il y a déjà beaucoup d’articles sur le sujet donc je ne m’y étendrait pas. Par contre petit tuyau, pour aller plus vite j’utilise le plugin swFunctionalTestGenerationPlugin qui permet de générer un « stub » de test fonctionnel symfony directement depuis les actions que l’on effectue dans la navigateur, pratique !

Il n’y a pas que les tests fonctionnels dans la vie, il y a également les tests unitaires. Comme JUnit pour Java, on a le droit à PHPUnit pour PHP mais je ne l’ai pas encore essayé. J’utilise Lime, un framework de tests embarqué dans symfony, écrit par Maître @fapbot. Au lieu des classiques assertTrue(), assertFalse(), on dispose des méthodes is(), isnt(), … Comme pour les tests fonctionnels, l’écriture de tests unitaires est très intuitive.

Grâce à ces tests unitaires, mon code est contrôlé et je n’ai plus à me soucier d’éventuels effets de bord. Je sais exactement comment se comportent mes méthodes et mes objets. Je blinde ainsi mon modèle, ce qui fait une chose de moins à me soucier. Je passe 50% de mon temps à écrire du code dans mes actions et vues, 20% de mon temps à écrire du code dans mon modèle, 20% à écrire mes tests et le reste à boire du café… Je ne me soucis pas du reste, mon environnement de test est complètement découplé de mon environnement de dev et l’environnement de prod est distant.

Sauf que… lancer les tests c’est long et j’aime pas trop attendre. Je me suis tourné vers des outils qui font le boulot à ma place. C’est ce que l’on appelle des serveurs d’intégration continue. Je regrette de ne pas avoir pu tester Sismo, le serveur d’intégration continue (CI) de Sensio Labs (vous savez, le même que plus haut, décidément !).

J’ai testé Hudson et phpUnderControl (cruiseControl). Pour ce dernier, je n’en suis pas très satisfait avec symfony et Lime. Il fonctionne bien, l’utilisation de Ant fait plaisir mais je n’ai pas pu profiter de toutes les possibilités de ce serveur. Je l’ai donc laissé tombé au profit d’Hudson. C’est un serveur plaisant, rapide à prendre en main, très lisible et parfaitement customisable avec le nombre incommensurable de plugins dont il dispose. Pour savoir comment le faire fonctionner avec symfony, on lit cet article de Nicolas Perriault. Pour ma part, je n’utilise pas SVN mais Git, il suffit d’installer le plugin qui va bien.

Voilà, sachant que mon Gmail est tout le temps ouvert et que j’ai le checker qui va bien dans Chrome, je suis alerté assez rapidement par mail si je casse tout. Encore quelque chose de moins à me soucier. C’est ce qu’on appelle, je crois, l’efficience et la productivité s’en porte beaucoup mieux.

Il me reste cependant quelque chose à éclaircir : TDD. Test Driven Development ou Développement piloté par les tests. Pour faire simple, avant de développer une fonctionnalité, je réfléchis. Oui mais je réfléchis deux fois puis trois fois même. C’est-à-dire que je cherche comment l’écrire, comment elle pourrait mal se comporter et comment la tester. Ensuite, je prends le chemin inverse. J’écris mes tests, je veille à son comportement lors de son écriture. Et voilà, ma fonctionnalité est écrite, les tests passent, je continue mon travail. Je ne passe pas 30 minutes à chercher ce qui ne va pas…

Au fait, pourquoi cet intitulé d’article ? C’est une interrogation qui vient des cours de qualité logiciel que j’ai pu avoir auparavant. J’ai toujours gardé cette phrase à l’esprit lorsqu’on me parle de tests. La question n’est pas si simple qu’elle en a l’air. Si vous avez une idée, les commentaires sont fait pour cela. Moi, je garde mon idée

En résumé, j’ai passé de bonnes vacances

Related Posts

• symfony rencontre Hudson, Mantis et les autres
• Tests unitaires et fonctionnels sur un Bundle en Symfony2
• Symfony, Jenkins & co
• Symfony live 2011
• Création automatique d’un projet symfony + MySQL + Git et Apache2

Cette erreur engendre une erreur 500. C’est un peu dommage… Il s’agit simplement d’un problème de droits sur les fichiers mais aussi sur les dossiers.

Les fichiers doivent posséder les droits 644 (-rw-r–r–) et les dossiers les droits 705 (drwx—r-x). Pour les fichiers, ces droits sont classiques, pour les dossiers on peut surement faire mieux mais là, ça marche, c’est testé. Pour faire ça vite :

Ensuite, on passe un coup de project:permissions et le tour est joué. On notera que la seule commande :

ne suffit pas à résoudre les problèmes de droits.

On fixera les droits du .htaccess à 604. Voilà

Related Posts

• Création automatique d’un projet symfony + MySQL + Git et Apache2
• Symfony, Jenkins & co
• Symfony live 2011
• symfony rencontre Hudson, Mantis et les autres
• Déploiement automatisé avec Capistrano et Git pour symfony et Diem