William's Blog » Symfony

Symfony, Jenkins & co

Will — Tue, 22 Mar 2011 00:34:26 +0000

Bonjour,

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:

phing main -DprojectName=$JOB_NAME

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.

version="1.0"?>
name="Symfony">
>symfony coding standard>

ref="Generic.WhiteSpace.DisallowTabIndent"/>

ref="Symfony.WhiteSpace.ScopeIndent"/>

ref="Generic.ControlStructures.InlineControlStructure"/>

ref="Symfony.ControlStructures.ControlSignature"/>

ref="Generic.Formatting.SpaceAfterCast"/>

ref="Generic.Functions.CallTimePassByReference"/>

ref="Generic.PHP.LowerCaseConstant"/>

ref="Squiz.Arrays.ArrayBracketSpacing"/>

ref="Squiz.ControlStructures.ElseIfDeclaration"/>

ref="Squiz.ControlStructures.ForEachLoopDeclaration"/>

ref="Squiz.ControlStructures.ForLoopDeclaration"/>

ref="Squiz.ControlStructures.LowercaseDeclaration"/>

ref="Squiz.PHP.LowercasePHPFunctions"/>

ref="Squiz.Scope.MemberVarScope"/>

ref="Squiz.Scope.MethodScope"/>
>

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

Symfony live 2011

Will — Wed, 02 Mar 2011 17:05:58 +0000

J’y serai !

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

symfony rencontre Hudson, Mantis et les autres

Will — Fri, 27 Aug 2010 09:51:53 +0000

Bonjour, depuis un certain temps déjà, je me pose deux questions : « comment améliorer mon travail ? » et… « Comment améliorer mon travail ? ». La première question traite essentiellement de ce que je produis, du code écrit, des fonctionnalités que je mets en place, … tandis que la deuxième question définit mes conditions de travail. Autrement dit, qu’est-ce qui va faire la différence entre tout le monde et moi (jeune entrepreneur) ? Et qu’est-ce qui va me faciliter la vie et ainsi impacter la première question ?

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 :

fix issue 0000007

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

name="phpcs">
msg="PHP CodeSniffer..." />
command="phpcs --standard=Symfony --report=checkstyle ${workspace}/apps ${workspace}/lib/filter ${workspace}/lib/form ${workspace}/lib/model ${workspace}/lib/validator ${workspace}/test" > ${workspace}/log/checkstyle.xml" escape="false">>
>

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 :

name="pdepend">
msg="PHP Depend..." />
command="pdepend --jdepend-xml=${workspace}/log/jdepend.xml ${workspace}/apps,${workspace}/lib/filter,${workspace}/lib/form,${workspace}/lib/model,${workspace}/lib/validator,${workspace}/test" escape="false" />
>

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 :

name="phpcpd">
msg="PHP Copy/Paste..." />
command="phpcpd --log-pmd ${workspace}/log/pmd.xml ${workspace}/apps ${workspace}/lib/filter ${workspace}/lib/form ${workspace}/lib/model ${workspace}/lib/validator ${workspace}/test" escape="false" />
>

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 :

name="phpdoc">
msg="PHP Documentor..." />
title="API Documentation"
destdir="${workspace}/doc"
sourcecode="yes"
defaultpackagename="sfProjetsGagnants"
output="HTML:Smarty:PHP">
dir="./apps">
name="**/*.class.php" />
>
dir="./lib/model">
name="**/*.class.php" />
name="**/Base*" />
>
>
>

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.

cd $WORKSPACE && phing main -Dworkspace=$WORKSPACE

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.

Création automatique d’un projet symfony + MySQL + Git et Apache2

Will — Sun, 15 Aug 2010 19:23:02 +0000

On ne crée pas de projets symfony tous les jours c’est vrai, mais le processus est souvent le même. En plus de cela, je trouve les manip’ un peu pénible quand il faut toucher à la configuration Apache2. Inspiré de cet article http://www.nacho-martin.com/automating-the-creation-of-new-symfony-1-4-projects-doctrine-git, j’ai écrit ma propre commande incluant la configuration d’un vhost Apache2. Je la partage ici.

Voici donc le script mkSfProject :

#!/bin/bash

SYMFREPO="http://github.com/vjousse/symfony-1.4.git"
DBUSER="us3r"
DBPASS="p4ssw0rd"
VENDOR_DIR="lib/vendor/symfony"
AUTHOR="William DURAND "
PHP="/usr/bin/php"

if [ -z "$DBPASS" ]; then
echo edit $0 to add your mysql password on line 4: DBPASS=\"password\"
exit
fi

if [ -z "$1" ]; then
echo usage: $0 project_name
exit
fi

# Create the project directory
mkdir $1
cd $1

git init
git clone $SYMFREPO $VENDOR_DIR
git submodule add $SYMFREPO $VENDOR_DIR/

git submodule foreach 'git submodule init && git submodule update'

git commit -m 'Initial commit; initialized symfony-git (1.4)'

# Generate the project
$PHP $VENDOR_DIR/data/bin/symfony generate:project $1

# Configure the author
$PHP symfony configure:author "$AUTHOR"

# Create the .gitignore file
echo "config/databases.yml" > .gitignore
echo "cache/*" >> .gitignore
echo "log/*" >> .gitignore

# Fix permissions
$PHP symfony project:permissions

# Commit
git add .
git commit -m 'Initialized symfony project'

# Generate a default app and commit
$PHP symfony generate:app frontend
git add .
git commit -m 'Initialized frontend application'

# Create the database and configure it in symfony
mysqladmin -u$DBUSER -p$DBPASS create $1
$PHP symfony configure:database "mysql:dbname=$1;hostname=localhost" $DBUSER $DBPASS

# Create the local URL
URL_PROJECT=`echo "$1.local" | tr '[[:upper:]]' '[[:lower:]]'`

# vhost config
sudo echo "

ServerName $URL_PROJECT

DocumentRoot \"`pwd`/web\"
DirectoryIndex index.php

\"`pwd`\">
AllowOverride All
Allow from all

Alias /sf \"`pwd`/lib/vendor/symfony/data/web/sf\"
\"`pwd`/lib/vendor/symfony/data/web/sf\">
AllowOverride All
Allow from All

" > "/etc/apache2/sites-available/$1"

# Add local url in /etc/hosts
sudo echo "127.0.0.1 $URL_PROJECT" >> /etc/hosts

# Enable the vhost
sudo a2ensite $1

# Reload Apache2
sudo /etc/init.d/apache2 reload

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

Déploiement automatisé avec Capistrano et Git pour symfony et Diem

Will — Wed, 11 Aug 2010 09:09:24 +0000

Hier, j’introduisais mes directives de travail. Aujourd’hui je vais introduire un sujet souvent sensible : la mise en production. C’est une tâche qui peut être critique mais si l’on prend toutes les précautions, nous limitons les risques. On notera bien que le facteur chance est laissé à la porte pour ce genre de manipulation…

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 :

capify .

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 :

set :scm, "git"
set :repository, "~/#{application}.git"
set :branch, "master"
set :checkout, "export"
set :deploy_via, :remote_cache

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 :

# Port
set :port, 9999
# App ?
set :application, "project_name"

# Where ?
set :deploy_to, "/var/www/#{application}"

# Which server ?
role :app, "localhost"
role :web, "localhost"
role :db, "localhost", :primary => true

# Who ?
set :user, "myUs3r"
set :password, "p4ssw0rd"

# More config
set :keep_releases, 3
ssh_options[:forward_agent] = true

# Path to php executable
set :php, "/usr/bin/php"

# Symfony application name (used for migrations)
set :sf_app, "front"
# Symfony web directory (www, web, public_html, ...)
set :sf_webdir, "www"

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 :

/var/www/project_name
`_ current (symlink)
|_ releases
|_ shared

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.

namespace (:deploy) do

desc < <-DESC
[internal] Overriding original task to fit to symfony project needs
DESC
task :finalize_update, :except => { :no_release => true } do
# Fix permissions
run "cd #{latest_release} && find * -type f -exec chmod 644 {} \\;"
run "cd #{latest_release} && find * -type d -exec chmod 705 {} \\;"

run < <-CMD
rm -rf #{latest_release}/log &&
ln -s #{shared_path}/log #{latest_release}/log
CMD

run <<-CMD
rm -rf #{latest_release}/cache &&
ln -s #{shared_path}/cache #{latest_release}/cache
CMD

stamp = Time.now.utc.strftime("%Y%m%d%H%M.%S")
asset_paths = %w(images css js).map { |p| "#{latest_release}/#{sf_webdir}/#{p}" }.join(" ")
run "find #{asset_paths} -exec touch -t #{stamp} {} ';'; true", :env => { "TZ" => "UTC" }
end

desc < <-DESC
Overriding original task to exclude restart
DESC
task :default do
update
end

desc <<-DESC
Overriding original task to use symfony migrations
DESC
task :migrations do
update
#sf.migrate
end

after "deploy:update", 'deploy:customize'

desc <<-DESC
Custom tasks
DESC
task :customize do
sf.symlinks
sf.remove_dev_environments
# clear cache
sf.cc
# Diem
dm.cc
dm.setup
end

end

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 :

namespace (:sf) do

desc < <-DESC
Run the "doctrine migration" task
DESC
task :migrate do
run "cd #{current_path} && #{php} symfony doctrine:generate-migrations-diff && #{php} symfony doctrine:migrate"
end

desc <<-DESC
Run the "symfony cc" task
DESC
task :cc do
run "cd #{current_path} && #{php} symfony cc"
run "cd #{current_path} && rm -rf cache/*"
end

desc <<-DESC
Create symlink to symfony specific targets
DESC
task :symlinks do
# symlink to database.yml
run "rm -rf #{current_path}/config/databases.yml"
run "ln -s #{shared_path}/databases.yml #{current_path}/config/databases.yml"

# symlink to uploads
run "rm -rf #{current_path}/#{sf_webdir}/uploads"
run "ln -s #{shared_path}/uploads #{current_path}/#{sf_webdir}/uploads"

# symlink to .htaccess
run "rm -rf #{current_path}/#{sf_webdir}/.htaccess"
run "ln -s #{shared_path}/.htaccess #{current_path}/#{sf_webdir}/.htaccess"

# symlink to app.yml
run "rm -rf #{current_path}/apps/#{sf_app}/config/app.yml"
run "ln -s #{shared_path}/app.yml #{current_path}/apps/#{sf_app}/config/app.yml"
end

desc <<-DESC
Remove DEV environments
DESC
task :remove_dev_environments do
run "rm -rf #{current_path}/#{sf_webdir}/*dev.php"
end

desc <<-DESC
Disable symfony application
DESC
task :disable do
run "cd #{current_path} && #{php} symfony project:disable #{sf_app} prod"
end

desc <<-DESC
Enable symfony application
DESC
task :enable do
run "cd #{current_path} && #{php} symfony project:enable #{sf_app} prod"
end
end

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

namespace (:dm) do

desc < <-DESC
Run the "Diem setup" task
DESC
task :setup do
run "cd #{current_path} && #{php} symfony dm:setup"
end

desc <<-DESC
Clear Diem cache and fix permissions
DESC
task :cc do
run "rm -rf #{current_path}/#{sf_webdir}/cache"
run "mkdir #{current_path}/#{sf_webdir}/cache"
run "chmod 777 #{current_path}/#{sf_webdir}/cache"
end

end

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 :

set :deploy_via, :copy

# Use copy to bypass firewall...
set :copy_strategy, :export
set :copy_cache, "/tmp/#{application}"
set :copy_exclude, [".git/*"]
set :copy_compression, :gzip

Cette configuration est largement inspirée de ces articles :

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

Faut-il tester… les tests ?

Will — Tue, 10 Aug 2010 11:39:33 +0000

Avec ce titre très accrocheur, vous allez surement penser que je vais vous parler de tests et vous avez raison… Mais de quels tests et pourquoi d’abord ?

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 :

/**
* Functional test file
*
* @author William DURAND
*/

include(dirname(__FILE__).'/../../bootstrap/functional.php');
include(dirname(__FILE__).'/../../bootstrap/doctrine.php');

$browser = new sfTestFunctional(new sfBrowser());

// Auto-generated
$test = $browser->test();
$conn = Doctrine::getConnectionByTableName('Commande');

$conn->beginTransaction();

// Get the form
$browser
->call('/commande/new', 'GET', array())
->with('request')->begin()
->isParameter('module', 'commande')
->isParameter('action', 'new')
->end()
->with('response')->begin()
->info('1.1 - Get the "Commande" form')
->isStatusCode(200)
->checkElement('#content > p', '#Nouvelle commande#')
->end()
;

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

L’erreur « suexec policy violation » avec symfony (chez OVH…)

Will — Fri, 16 Jul 2010 12:57:12 +0000

Bonjour, je laisse ici un petit rappel pour avoir lutté quelques heures avec une erreur 500, au début incompréhensible… Il s’agit de l’erreur :

suexec policy violation: see suexec log for more details

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 :

find * -type f -exec chmod 644 {} \;

find * -type d -exec chmod 705 {} \;

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

php symfony project:permissions

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

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

Intégrer un gestionnaire de fichiers dans dmCkEditorPlugin

Will — Tue, 06 Jul 2010 00:09:45 +0000

Bonjour,

je laisse ici une petite astuce pour intégrer KFM (http://kfm.verens.com/), un excellent gestionnaire de fichiers en AJAX, au plugin Diem nommé dmCkEditorPlugin. Ce plugin offre un nouveau widget contenant, comme son nom l’indique, l’éditeur WYSIWYG CkEditor.

Pour installer KFM, on télécharge la dernière version que l’on place dans dmCkEditorPlugin/js/kfm.

Ensuite on ouvre dmCkEditorPlugin/config/dm/config.yml et on ajoute cette ligne :

default:
ckeditor:
config:
...
filebrowserBrowseUrl: /dmCkEditorPlugin/js/kfm/index.php

KFM utilise une base de données, il faut donc la configurer. Le choix que j’ai fait est de parser le fichier databases.yml afin de récupérer les paramètres de connexion directement. Il faut donc modifier le fichier de configuration de KFM (dmCkEditorPlugin/js/kfm/configuration.php). J’ai placé ce code tout en haut en remplaçant les variables en rapport avec la base de données :

require_once(dirname(__FILE__).'/../../../../lib/vendor/diem/symfony/lib/yaml/sfYaml.php');

$config = sfYaml::load(dirname(__FILE__).'/../../../../config/databases.yml');

$dsn = $config['all']['doctrine']['param']['dsn'];
preg_match('#(?P\w+):host=(?P\w+);dbname=(?P\w+);#', $dsn, $matches);

// what type of database to use
// values allowed: mysql, pgsql, sqlite, sqlitepdo
$kfm_db_type = $matches['type'];
// the following options should only be filled if you are not using sqlite/sqlitepdo as the database
$kfm_db_prefix = 'kfm_';
$kfm_db_host = $matches['host'];
$kfm_db_name = $matches['dbname'];
$kfm_db_username = $config['all']['doctrine']['param']['username'];
$kfm_db_password = $config['all']['doctrine']['param']['password'];
$kfm_db_port = '';

C’est une manière simple et efficace d’intégrer ce gestionnaire de fichiers. Ce n’est pas parfait mais fonctionnel

Connaissiez-vous … la commande Symfony/Doctrine qui fait le ménage ?

Will — Wed, 30 Jun 2010 11:35:42 +0000

En développant avec Symfony on est parfois amené à supprimer des classes dans notreschema.yml, sauf que Symfony ne supprime pas tout ce qui a été généré automatiquement avec Doctrine.

Une petite commande a été introduite depuis la version 1.4 de Symfony :

php symfony doctrine:clean-model-files

Elle détermine les fichiers du modèle à supprimer en se basant sur le schema.yml courant.

http://www.symfony-project.org/reference/1_4/fr/16-Tasks#chapter_16_sub_doctrine_clean_model_files

Définir un nouveau comportement pour le modèle Doctrine et représenter intelligemment des objets en Symfony

Will — Thu, 06 May 2010 13:26:44 +0000

Lors d’une utilisation poussée de Doctrine on peut être amené à vouloir redéfinir le comportement par défaut de notre modèle. Pour cela, on peut intercaler notre propre couche entre le code de base de Doctrine et le code généré.

La première chose à faire est d’indiquer à Doctrine notre sur-couche en éditant le fichier config/ProjectConfiguration.class.php :

class ProjectConfiguration extends sfProjectConfiguration
{
public function setup()
{
// ...

// custom config Doctrine
sfConfig::set('doctrine_model_builder_options', array(
'baseTableClassName' => 'MyDoctrineTable',
'baseClassName' => 'MyDoctrineRecord'));
}
}

Ensuite, on va créé nos deux classes personnalisées. Bien évidemment les deux classes héritent des classes de base de Doctrine :

class MyDoctrineTable extends Doctrine_Table
{
// ...
}

class MyDoctrineRecord extends sfDoctrineRecord
{
// ...
}

Une fois les nouveaux comportements écrits, il suffit de générer à nouveau le modèle :

symfony doctrine:build-model

Les classes qui étendent MyDoctrineRecord seront instantanément modifiées (puisqu’on va redéfinir le extends des classes Base*). Pour les classes *Table, les existantes devront être modifiées à la main, les nouvelles classes seront par contre définies correctement.

Si vous ne l’avez pas encore remarqué, Doctrine est capable de deviner un meilleur attribut à afficher lorsqu’on affiche un objet. Par exemple :

public function executeIndex(sfWebRequest $request)
{
$this->admin = Doctrine::getTable('Administrateur')->findOneByIdentifiant('admin');
}

echo $admin ?>

// Affichera "1", l'id de l'administrateur

Mais si nous avions à faire à un article avec un title, alors le titre serait affiché. En fait, des champs sont prédéfinis dans Doctrine.

Ce qui peut être intéressant, c’est de pouvoir gérer ces champs parce que par défaut ils sont hardcodés : name, title, description, subject, keywords et bien sûr id.

Pour cela, ce qui précède va nous être utile. Créons le fichier de configuration config/settings.yml :

# config/settings.yml
all:
doctrine:
identifier_fields: [identifiant, foo, bar, id] # Preference order

Nous pourrons ainsi définir nos propres identifiers. Ensuite, redéfinissons le comportement d’un enregistrement Doctrine :

class MyDoctrineRecord extends sfDoctrineRecord
{
public function __toString()
{
try
{
return (string) $this->get($this->table->getIdentifierColumnName());
}
catch(Exception $e)
{
$guesses = array('name',
'title',
'description',
'subject',
'keywords',
'id');

// we try to guess a column which would give a good description of the object
foreach ($guesses as $descriptionColumn)
{
try
{
return (string) $this->get($descriptionColumn);
}
catch (Exception $e1) {}
}
}

return sprintf('No description for object of class "%s"', $this->getTable()->getComponentName());
}
}

C’est une simple adaptation de la méthode __toString() par défaut. On ajoute juste un appel à la méthode getIdentifierColumnName() que nous allons définir ci-après.

class MyDoctrineTable extends Doctrine_Table
{
/**
* Find a column name that represents a record
*/
public function getIdentifierColumnName()
{
/* config/settings.yml */
$columns = array_intersect(sfConfig::get('sf_doctrine_identifier_fields'), $this->getColumnNames());

if(!$columns[0])
{
/* identifier column names */
$columns = $this->getIdentifierColumnNames();

if(!$columns[0])
{
/* Default: the first column */
$columns = $this->getColumnNames();
}
}

return $columns[0];
}
}

Cette redéfinition permet d’utiliser notre configuration d’écrite dans le fichier config/settings.yml. On tente de trouver un meilleur attribut, si ce n’est pas le cas on fait appel à la méthode getIdentifierColumnNames() qui retourne un tableau d’identifiers créés à l’initialisation. Si cela ne fonctionne toujours pas, on retourne la première colonne de la table.

En reprenant notre exemple, nous obtenons :

public function executeIndex(sfWebRequest $request)
{
$this->test = Doctrine::getTable('Administrateur')->findOneByIdentifiant('admin');
}

echo $admin ?>

// Affichera "admin", l'identifiant de l'administrateur

Ceci peut, à mon sens, être utile.

William's Blog » Symfony

Symfony, Jenkins & co

Related Posts

Symfony live 2011

Jeudi

Vendredi

Related Posts

symfony rencontre Hudson, Mantis et les autres

Mantis

Hudson

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

Checkstyle : mon code a du style !

Pdepend : analyse de code statique

DRY ! Analyser les répétitions de code

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

Invoquer Phing

Couverture de code

Conclusion

Related Posts

Création automatique d’un projet symfony + MySQL + Git et Apache2

Related Posts

Déploiement automatisé avec Capistrano et Git pour symfony et Diem

Related Posts

Faut-il tester… les tests ?

Related Posts

L’erreur « suexec policy violation » avec symfony (chez OVH…)

Related Posts

Intégrer un gestionnaire de fichiers dans dmCkEditorPlugin

Related Posts

Connaissiez-vous … la commande Symfony/Doctrine qui fait le ménage ?

Related Posts

Définir un nouveau comportement pour le modèle Doctrine et représenter intelligemment des objets en Symfony

Related Posts