Ze Technology

Bien connu des développeurs Java, Ant est un build-system, à l’instar des Makefiles, permettant d’automatiser le déploiement d’un projet. Bon nombre de projets PHP ne sont en effet pas directement utilisables tout de suite après récupération des sources, et/ou nécessitent un certain nombre d’adaptation en fonction du serveur sur lequel le projet est déployé. Voire même, parfois, certaines tâches de maintenances assez rébarbatives pourraient être automatisées.

Je ne connais même pas Ant !

Pour ceux qui ne connaissent pas du tout Ant (et je ne parle pas d’un diminutif d’Antoine…), les rouages tournent concrètement grâce à un fichier XML classiquement nommé « build.xml », comprenant une succession de balises du style :

<target name="NOM_REGLE" depends="REGLES À EFFECTUER AUPARAVANT">
     <actions à effectuer ... />
</target>

Une fois ce fichier XML dûment rempli, vos règles s’exécutent par le biais d’une ligne de commande, après bien entendu avoir vérifié qu’Ant était bien installé sur votre machine :
> ant NOM_REGLE

Il y a un certain nombre d’options disponibles, il est par exemple possible d’afficher les règles disponibles et leur rôle respectif via ant -p pour peu que vous ayez renseigné un champ « description » dans le fichier build.xml.

Bon, et pour mon projet, ça sert à quoi ?

Vous manquez d’imagination ? Voici à titre d’exemple la liste de règles que j’ai définie pour Piwam :

• init: Créer les répertoires manquants (log, cache, build…
• cc: Vider le cache
• doc: Générer la documentation Doxygen
• up: Update SVN
• phpcpd: Cherche le code PHP dupliqué au sein du projet
• pdepend: Génère un rapport de dépendance des classes
• phpcs: Vérifie la conformité du code avec une norme donnée
• lint: Vérifie qu’aucun fichier ne contient une erreur de syntaxe
• test: Lance les tests unitaires et fonctionnels
• css: Concatène l’ensemble des fichiers CSS en un seul grand fichier CSS
• css.min: Minimise la taille du gros fichier CSS. (appelle automatiquement la règle css en amont)
• clear: Nettoie les fichiers générés
• build: Lance l’ensemble des tâches permettant de vérifier la qualité du projet

je vous invite à découvrir le fichier XML correspondant sur le dépôt SVN du projet. Ce fichier vous permet alors d’effectuer toute une batterie d’actions de manière extrêmement simplifiée. Ant est utilisé au sein d’une multitude d’outils du monde Java, des IDE (Eclipse…) aux outils d’intégration (Hudson, CruiseControl…). En pratique, ces outils vont aller lire votre fichier build.xml et appeler les commandes correspondant aux tests (dans mon cas : phpcs, pdepend, etc.) de manière 100% automatisée afin de vous permettre de suivre l’évolution de votre projet au fil des révisions.
Sur ce, je vous laisse rédiger votre propre antfile, en attendant de vous présenter comment l’exploiter au sein d’Hudson dans un projet article !

Liens utiles

• http://ant.apache.org : Site officiel de Ant, par la fondation Apache
• http://phing.info : Alternative à Ant spécialement conçue pour les outils PHP. (Basée sur Ant)
• http://hudson-ci.org : Hudson, outil d’intégration continue

Aux débuts de Piwam, les relations décrites dans le fichier schema.yml n’étaient pas nommées explicitement. Du coup, lors de la génération du schmilblick par Propel (Model + SQL), c’est InnoDB qui s’occupait de trouver un nom à ces relations.

Aujourd’hui, j’écris le script permettant de migrer de Piwam 1.1.2 vers Piwam 1.2, script qui nécessite d’effectuer des opérations sur des foreign keys, en l’occurence les supprimer… Comment diable alors faire référence à une clé étrangère dont on ne connait pas le nom ? Après avoir farfouillé partout sur la toile, il apparaît qu’il n’y a pas moult solutions pour arriver à mes fins. On se retrouve ainsi soit à écrire des procédures, soit à faire appel à l’information_schema. Enfin, certains proposent une utilisation de SHOW TABLE avec les arguments qui vont bien, puis parser la sortie pour récupérer les noms des contraintes. J’ai pu par ailleurs découvrir la version Firebird :

SELECT RDB$CONSTRAINT_NAME
FROM RDB$RELATION_CONSTRAINTS
WHERE RDB$CONSTRAINT_NAME LIKE 'FK%' AND
RDB$RELATION_NAME='MATABLEAMOI'
ORDER BY RDB$CONSTRAINT_NAME

Ne pouvant exécuter de requêtes propres à Firebird, ni même de procédures (Piwam tourne sous trop de types de serveurs différents aux configurations et autorisations bien différentes), j’ai finalement opté pour une solution ma foi fort simple. Accrochez-vous, c’est du SQL de très haut niveau (hum…).

CREATE TABLE ma_table_copy AS SELECT * FROM ma_table;

Une copie réalisée de la sorte a pour effet de ne copier que la structure et la table, en omettant indexes et contraintes. Lent, mais portable (je ne sais pas si l’adjectif est vraiment adapté) et pratique. Tout ça pour dire, bordel, une bonne fois pour toutes, n’oubliez pas de nommer vos contraintes explicitement, ça facilite grandement la maintenance !

Ce billet fait suite à l’article « Comment je teste #2″, qui se finissait par quelques conseils sur le profiling et l’amélioration de son code. Je vous propose de consulter une présentation réalisée par un certain George S, présentation qui fait le tour d’un large panel de possibilité pour développer du code dit « scalable » en passant donc par la configuration du serveur, l’analyse des soucis et les bonnes pratiques à adopter.

GCD, comme on l’appelle, est disponible sous forme d’une bibliothèque libre, publiée par la firme de Cupertino. GCD introduit avec Snow Leopard des possibilités aisées de parallèlisation, offrant aux développeurs un moyen simple de tirer partie des processeurs multi-coeurs.
Site officiel

Et c’est partie pour le premier article de la série. Après une entrée en matière, voici l’heure pour moi d’écrire, et pour vous de lire, l’épisode #1 de la série. Il n’y a pas d’ordre particulier, les sujets seront abordés assez indépendamment. En revanche, les articles seront illustrés d’un cas d’utilisation réel : Piwam.

Aujourd’hui, je vous propose, et vous n’avez pas vraiment le choix, de découvrir la manière dont je teste le déploiement de l’application. Quels sont les pièges, les méthodes, bref, tout.

Virtualiser, c’est la mode.

Je ne possède pas de serveur de test. Et de toute manière, si j’en possédais un, je me servirais tout de même d’un système virtualisé, afin d’éviter d’utiliser inutilement le vrai serveur. Voilà donc le premier point : le déploiement est testé en conditions réelles au sein d’une machine virtuelle. Le système virtualisé est le plus proche possible de celui qui tourne en production : OS, noyau, mémoire disponible, swap, version de PHP, MySQL, fichiers de configuration…

Serveur Debian virtualisé, lancé depuis WindowsXP

Cette précaution permet de s’affranchir au maximum des mauvaises surprises liées à l’environnement. Imaginez un peu, votre système sur lequel vous développez possède le paramètre memory_limit fixé à 128M. Tout fonctionne parfaitement. Sans passer par le scénario de test de déploiement présenté ici, vous décidez de mettre tout de suite à jour la version en production. Tout fonctionne parfaitement. Erreur. Tout semble fonctionner parfaitement. C’était sans compter cet utilisateur qui, voulant lister 100 résultats de recherche par page, obtient une magnifique erreur d’explosion de la mémoire allouée, dont le maximum était fixé à 64M sur le serveur de production.

Quelle solution choisir ?

Les solutions de virtualisation ont le vent en poupe actuellement. Citons VM Ware, VirtualBox, Parallels (MacOSX)… Pour laquelle opter ? Après un essai des différentes solutions, je ne peux que vous conseiller la solution de Sun (Oracle…) : VirtualBox. Disponible sous toutes les plate-formes, gratuite, libre, cette box magique satisfaira toute nos exigences. Une fois installée, installez votre système virtualisé (dans mon cas : Debian 5.0), installez / configurez vos applications (ici : Apache 2, PHP 5.3 + modules, MySQL 5.1, symfony 1.2).

Envoyer ses fichiers au serveur

C’est bien joli d’avoir maintenant une réplique de son serveur de production, mais comment y tester son application ? Plusieurs solutions :

1. Vous recodez intégralement votre projet au sein de votre serveur virtualisé (…)
2. Vous avez pris la bonne habitude d’utiliser un serveur CVS, SVN ou Git. Dans cas là, un commit d’un côté et un update de l’autre fera très bien l’affaire.
3. Vous avez configuré un répertoire partagé sous VirtualBox, accessible aussi bien sous votre système hôte que depuis votre serveur. Placez donc juste l’archive du projet à tester dans ce répertoire.

Et maintenant, je fais quoi ?

Pour résumer, vous possédez maintenant une version à jour de votre application, disponible sur un serveur (virtualisé), réplique parfaite (normalement) du serveur qui l’accueillera. Et bien, rappelez vous pourquoi vous venez de faire toutes ces manipulations : pour tester ! Suivez donc la procédure de déploiement de votre application que vous avez pu décrire au sein de votre documentation. Pour certains projets, il n’y a rien à faire de particulier, le projet est directement fonctionnel, mais pour d’autres, c’est le moment de vérifier que votre documentation, bêtement suivie à la lettre, permet d’arriver à une application qui fonctionne ; quelques exemples en vrac :

• Configuration de l’accès au SGBDR
• Droits en lecture/écriture de certains répertoires
• Mises à jour de fichiers
• Exécution de requêtes pré-requises

Si, une fois, les instructions de la documentation suivies, votre application ne fonctionne pas, c’est qu’il y a bien un problème, lié à la documentation ou à l’application.

Youpi ! Ça fonctionne !

Allons allons, calmons nous. Le déploiement du projet (ou de la mise à jour) fonctionne. Nous ne sommes pas encore en mesure de savoir si le projet fonctionne à 100% comme il devrait. Il vous faut maintenant torturer votre application dans tous les sens afin de déceler les bugs éventuels. Ou alors, et je vais peut-être créer une certaine frustration en m’arrêtant ici, c’est le moment de lancer vos 2000 tests unitaires et fonctionnels, qui vérifieront automatiquement le bon fonctionnement de votre application sur le système courant.

Virtualiser, encore +

Il est fort possible que votre application ne soit pas destinée à une plate-forme en particulier mais  à être déployée sur un grand nombre de serveurs très différents, aux versions et configurations de PHP différentes. Vous pouvez alors virtualiser d’autres OS, aux configurations différentes. Ou vous pouvez pousser la virtualisation encore plus loin en optant pour VServer. Une fois VServer installé sur votre serveur de test, vous serez en mesure d’isoler parfaitement différents « sous-environnements » différents et de switcher d’une configuration à une autre extrêmement facilement, rapidement, et de manière très fiable, sécurisée parfaitement isolée.

En bref :

1. Installez VirtualBox
2. Virtualisez l’OS de votre choix
3. Configurez cet OS virtualisé
4. Testez, lancez vos tests

On regrette très vite de ne pas tester son application. Pendant les différentes phases du développement, il est on ne peut plus utile d’avoir un aperçu fidèle à la réalité de la qualité du produit qu’on s’apprête à délivrer.

Tests unitaires, tests fonctionnels. tests de déploiement, tests de non-régression… la batterie n’est pas mince, et automatiser un maximum de tâche s’avère payant.

La raison d’exister de cette nouvelle série d’article ne vas pas être de vous présenter une énième fois des cours théoriques sur les méthodologies de tests, mais de faire le point sur certaines problématiques, et d’apporter un élément de réponse parmi tant d’autres : le mien.

Vous retrouverez donc dès la rentrée une série d’articles sur cette passionnante thématique, permettant à chacun d’améliorer :

• sa productivité
• la qualité de son travail
• ses habitudes de développement

Le premier article est prévu pour la fin du mois, avec un case-study sur la manière dont je teste le déploiement de Piwam.

PS : Vous noterez les images très très drôles qui accompagneront dorénavant les articles dans la mesure du possible.

Cher ZeTechnology,

C’est aujourd’hui que je viens d’achever ma première application Flex. Flex ? Kézako ? Pour ceux qui ne connaîtraient pas du tout ce terme, Flex est une technologie développée par Adobe, basée sur ActionScript. Flex permet de mettre en place facilement des RIA (application avec interface riche) et, nous le verrons, c’est dans ce domaine qu’il excelle. Concrètement, une fois votre projet Flex compilé vous obtenez une application exécutable au sein d’un player Flash (ou très facilement en tant qu’application desktop grâce à Adobe Air). Des exemples d’utilisation de Flex :

• Un explorateur de styles
• Plein de samples sur les possibilités offertes
• Applications professionnelles

PureMVC est un framework MVC à l’origine mis en place pour ActionScript, qui depuis a été porté pour différentes plate-formes : PHP, ColdFusion, Java…

• Exemples d’utilisations de PureMVC

AmfPHP est une implémentation PHP de Action Message Format (AMF). AmfPHP permet ainsi une communication entre votre application Flex et un service écrit en PHP.

• Exemples d’utilisations d’AmfPHP

Maintenant que les présentations sont faites, l’heure des comptes est venue. Je viens de réaliser un gestionnaire de quizz. Mon application permet de gérer des listes de questionnaires, d’y ajouter des questions, réponses, images d’illustration… puis de « jouer » à ces questionnaires. L’application Flex, développée autour de PureMVC, appelle donc sans cesse mon script PHP s’occupant d’interagir avec MySQL pour enregistrer une nouvelle question, récupérer la liste des quizz, etc.

Ce que je retiens au final, c’est :

Une mise en place très rapide. L’installation de Flex Builder (l’IDE est basé sur Eclipse, disponible par ailleurs directement sous forme de plug-in),  de PureMVC et d’AmfPHP est très rapide, sans mauvaise surprise. La seule surprise était un soucis de fonctionnement du plugin Flex Builder avec Eclipse 3.5, qui venait juste de sortir à ce moment là. On excusera donc Adobe. Attention toutefois, Flex Builder n’est PAS gratuit, sauf pour les étudiants (licence sur simple demande).

L’apprentissage de Flex est assez rapide, l’IDE aidant. Le bon lot de composants existant permet de concevoir visuellement ses interfaces en Wysiwyg. Un des concepts à bien maitriser pour bien positionner ses éléments est celui des layouts assurant la mise en place des éléments, concept qu’on retrouve déjà dans pas mal d’autres technos. On apprend très vite à apprécier une propriété, [Bindable], permettant de lier constamment des éléments et valeurs. Le thème de base lassera très vite celui qui connaît bien la technologie mais est tout de même très agréable à l’oeil. Les composants sont immédiatement exploitables pour une vraie application, il y a même un système de barre de chargement lancée automatiquement au chargement votre interface.

PureMVC, quant à lui, nécessite une phase un peu plus longue d’apprentissage. Les notifications sont utilisées à outrance, ce qui autorise le développeur à commettre les pires goritudes dans son code. Les différentes couches (modèle, vue, contrôleur) communiquement efficacement entre elles, mais dans le cadre d’un développement en équipe, il faut bien veiller à ce que chacun aie les même habitudes que son collègue. Autrement, c’est l’anarchie chez les notifications.

En ce qui concerne AmfPHP, c’est quasiment que du bonheur.  Ça fonctionne très vite, très bien, il est vraiment aisé et rapide de transmettre des objets, des tableaux, du XML entre Flex et PHP.

À noter, une communauté vraiment active, et une documentation que je considère « correcte », qui manque peut être d’exemples. Au final, cette première expérience avec Flex, AmfPHP et PureMVC est plutôt concluante. Flex est à ce jour une solution qui commence à devenir assez mature. À retenir pour la réalisation d’interfaces homme-machine, de backoffices ou applications mettant en oeuvre génération de graphiques, saisie de données…

N’oubliez pas de visiter les démonstrations !

Sismo est un outil d’intégration continue développé par Sensio Labs (vous savez, symfony…). L’intégration continue, c’est la possibilité de détecter tout ce qui ne va pas au fil des versions. Du vert ou du rouge, ça passe ou ça ne passe pas, Sismo présente une interface très simple permettant de contrôler le comportement de ses projets au fil des releases. Fabien Potencier a annoncé sur le groupe de discussion « symfony developers« , une éventuelle disponibilité de ce projet libre à la fin du mois de juin.

Une démonstration en ligne du produit est disponible sur http://ci.symfony-project.org. Hâte d’essayer cette alternative à Xinc et consorts.

Il y a peu, une annonce était faite comme quoi MySQL travaillait sur un nouveau modèle de release. La trame générale de celui-ci est maintenant fixée et approuvée.

Dans les grandes lignes, on retrouve :

• Le trunk est toujours laissé dans une qualité de beta
• Les GA sortiront tous les 12 à 18 mois
• Pas plus de 2 releases avec un support actif
• Les milestones commencent lors de beta (jamais lors d’alpha) par un merge entre le trunk et le stage tree.

Pourquoi cet article ? Pas seulement pour relayer l’actualité MySQL, mais aussi pour tenter de sensibiliser un maximum de lecteurs sur l’importance d’un modèle de release adapté. Pour un logiciel prétendant à un minimum d’évolutions et d’activité, il est capital de trouver un compromis entre ce que je nommerai la rétro-utilisabilité et la publication des nouvelles versions. J’entends par « rétro-utilisabilité » le fait d’assurer aux utilisateurs des versions passées un support, un moyen de passer aux versions supérieures efficacement.

Source : Planet MySQL (En)

Ça y’est, vous êtes en train d’écrire vos tests fonctionnels pour votre application symfony. MAIS votre application – ou une partie – nécessite une identification de la part de l’utilisateur. Il y a bien sûr la solution qui consiste à systématiquement remplir le formulaire dans chaque fichier de test.

Je vous présente ici une solution pour palier à cela. La solution consiste à étendre la classe sfTestFunctional du framework. Ce qui donne, par exemple :

class sfGuardTestFunctional extends sfTestFunctional
{
 public function __construct($browser, $lime = null, $testers = array())
 {
   parent::__construct($browser, $lime, $testers);
   $this->signin(array('username' => 'foo', 'password' => 'bar'));
 }

 /**
  * Perform user authentication
  *
  * @param   array of String         $user_data
  * @return  sfGuardTestFunctional   $this
  */
 public function signin($user_data)
 {
   return $this->info(sprintf('Login as "%s"', $user_data['username']))->
          get('/admin/login')->
          click("S'identifier", array('login' => $user_data))->

          with('form')->begin()->
            hasErrors(false)->
          end()->

          with('user')->begin()->
            isCulture('fr_FR')->
            isAuthenticated(true)->
          end()->

          with('request')->begin()->
            isParameter('module', 'admin')->
            isParameter('action', 'login')->
          end()->

         isRedirected()->
         followRedirect();
 }
}

De cette manière, dans votre fichier de test il vous suffira d’instancier votre browser avec votre nouvelle classe :

$browser = new sfGuardTestFunctional(new sfBrowser('my_vhost'));

Et voilà, vous pouvez vous considérer comme identifié et écrire directement vos tests fonctionnels ! La solution présentée ici est minimale, la mise en forme du code PHP avec Blogspot n’étant pas des meilleure et votre motivation étant sans doute plus grande à déchiffrer 20 lignes de code plutôt que 42.

Une petite mise en oeuvre de ce cette classe, mise en place au sein de Piwam. L’exemple est destiné à la version 1.2 du framework..

• Tests fonctionnels avec symfony 1.2 et Propel
• Tests fonctionnels avec symfony 1.2 et Doctrine
• API symfony : sfTestFunctional
• Tests unitaires et fonctionnels avec symfony 1.2