« Release early, release often »

Cela s’apparente à la stratégie « Release early, release often »: déployer souvent montre que le projet progresse. Ces progrès ne sont pas toujours importants : parfois même, des bugs sont publiés. Mais durant la période de développement, c’est une situation normale. De toutes manières, une nouvelle version corrigera bientôt le problème. Et puisque le bug a été identifié tôt dans le processus, il sera donc plus facile à corriger, et aussi, plus important, plus facile à pardonner.

Toujours pas fini…

Comment peut-on fournir un code qui puisse toujours être mis à disposition ?

Eh bien, tout d’abord, entre la version et le code actuel, il ya une pièce d’ingénierie appelée SMC: Git, SVN, Mercurial, fossiles, CVS …( appelez cela comme vous voulez !), qui sera la principale source pour la version. Tant que vous ne commitez pas dans le SMC, votre code ne peut pas être publiable: il peut ne pas être compilé, ni être propre, ou non fonctionnel. Tant qu’il n’est pas commité,  le code n’existe pas.

Une fois qu’il est commité, il doit faire partie intégrante de l’application. Et pour être publiable, il ne doit pas casser l’application. La première vérification sera la compilation par PHP : si le code n’est pas compilé, alors, il ne sera pas publiable.

Développement bouchon de champagne

Le codage total, jusqu’à ce qu’il fonctionne, est aussi appelé le développement bouchon de champagne : vous ne savez le son que fera le bouchon de bouteille de champagne qu’à son ouverture. A ce stade, vous aurez eu soin d’avoir tous vos amis autour de vous, parce que si le bouchon saute, alors vous voudrez remplir quelques verres et trinquer. Par contre, si cela échoue, tous vos amis seront là pour vous remonter le moral ou se moquer de vous (oui, les amis font aussi cela).
Cette allégorie peut être appliquée au développement : quand le code est attendu depuis trop longtemps, les attentes s’accumulent, et commencent à grandir, jusqu’à devenir extrêmes. Puisque vous vous concentrez que sur le code, et laissez les utilisateurs dans le noir, alors ils trouveront les informations avec leur seul outil à leur disposition : l’imagination. Voilà comment vous vous retrouvez avec un beau projet, bien en deçà des attentes.

Largeur d’abord

L’autre approche est de rendre le code prêt dès que possible, même s’il n’est pas complet. Compiler est une première étape. Le fonctionnement complet n’est seulement que le troisième niveau. Entre les deux, vous avez le niveau «incomplet» : il fonctionne mais pas entièrement.

Prenons un exemple : comment travailler sur un module imaginaire de Drupal addressbook et l’avoir  fonctionnel pendant tout le dévelopement ? Si un tel module nécessite de plusieurs jours de travail, alors il ne fonctionnera pas entièrement les premiers jours. À ce stade, il n’est pas important de l’avoir entièrement opérationnel : nous voulons juste qu’il fonctionne.

Imaginez le stade précoce du module Drupal: le module lui-même est créé, basé sur son nom, avec beaucoup de « hooks » vides. Cela va compiler mais ne fera rien. Cependant, cela est publiable : il peut être envoyé sur une nouvelle version et n’ajoutera rien … à l’application finale.
Puis, à partir de cette base, vous pouvez commencer à ajouter de nouvelles pièces. Imaginez que vous travaillez sur le carnet d’adresses.

Vous avez alors différentes possibilités pour commencer à travailler : vous pouvez commencer à partir de la structure de la base de données et de mettre à jour hook_install ; puis ajouter quelques valeurs dans la base de données, et enfin travailler dans hook_view, de sorte que vous pouvez fournir une vue sur les données existantes, puis le même hook_view pour un formulaire requérant des données.
Vous pouvez également démarrer à partir hook_menu pour afficher le menu et un accès à votre nouveau module, puis  hook_view pour l’afficher. Enfin hook_install pour ajouter une nouvelle CSS au système de modèles. Vous pouvez aussi commencer par le panneau d’administration, les modèles, etc…
Chacune de ces approches vous donnera quelque chose de fonctionnel : vous et les utilisateurs seront en mesure d’exécuter cette application, et de voir le travail effectué ; bien sûr pas tout entièrement : le développement n’est pas encore fait mais seulement une partie.
C’est la principale différence avec le développement en profondeur. Une approche en profondeur résoud tous les problèmes qui se présentent : Drupal hooks, structure de la base de données, modèle, tests et déploiement. À tout moment, c’est un travail en cours et et rien n’est publiable : ce qui est fait est bien fait, mais on ne peut le faire marcher.

En fin de compte il ya deux approches différentes pour que cela soit toujours publiable.

• Croissance organique du code : commencer par déposer tout le code requis pour le faire fonctionner. Ensuite, ajoutez nouvelle fonctionnalité au dessus d’un tel code. J’appelle aussi cela « ajouter de la chair autour de l’os », basé sur le cliché du squelette. Vous finirez probablement avec beaucoup de fonctions vides ou constantes, qui seront des emplacements, ou « placeholders » pour un code plus complexe et ultérieur. Compter le nombre de ces emplacements est un bon indicateur des progrès réalisés.

• Code visible : cette approche est centrée sur les utilisateurs (ou clients, si vous préférez) . Ne travaillez que sur ce qui est visible. Ce formulaire de 120 champs ne commencera qu’avec deux formulaires. Puis, il affichera 3, puis 4, puis 12, puis 30, etc … A chaque fois, il va ajouter de nouvelles fonctionnalités. Et si c’est un tunnel  de paiement en 12 étapes, alors il devrait commencer par 1 étape de paiement, puis 2, etc … Gardez à l’esprit que les utilisateurs ne mesurent la progression que sur ce qu’ils voient (c’est-à-dire la vue), et non sur la quantité de travail ou de code que vous fournissez.

Si vous prévoyez de garder votre code publiable, vous devrez être en mesure de répondre à cette simple question : puis-je simplement déployer mon code maintenant ?

Cela vous rendra prêt pour n’importe quelle situation pouvant survenir en dehors  du planning : problème de sécurité, publication en urgence pour démonstration, changement soudain dans le planning client, ou même, un changement de développeur. Un code qui fonctionne bénéficiera toujours  à la personne suivante, plutôt qu’elle se batte avec un ensemble de tâches partiellement achevées.

Damien Seguy

Planifier, déployer et configurer l’environnement de Magento Enterprise Edition nécessite sans aucun doute d’apporter une grande attention aux moindres détails afin d’en obtenir les meilleures performances. La plate-forme physique, la performance du réseau, la configuration et l’optimisation des différents services ainsi que la configuration avancée de Magento Enterprise Edition jouent tous un rôle important pour aboutir au meilleur rendement possible sur votre configuration spécifique. Ce qui suit est la revue des points essentiels abordés dans le livre blanc de Varien:

• Il est fortement recommandé d’optimiser les configurations Apache et MySQL. Cela peut permettre d’augmenter les performances de 55 à 70%, en particulier sur les pages dynamiques. MySQL et Apache sont en effet configurés par défaut pour utiliser beaucoup moins de ressources que ce qu’un serveur moyen peut désormais fournir, et ne sont par conséquent pas en mesure de prendre en charge un nombre élevé de transactions simultanées. Cela peut conduire à une charge irrégulière du serveur et un comportement général imprévisible.

• L’ajout d’un accélérateur PHP est un autre aspect important de la configuration de l’environnement de Magento Enterprise Edition. eAccelerator affiche de bons résultats avec une augmentation de 40% à 600%. D’après nos tests, APC est encore plus efficace affichant un gain de performance supplémentaire de 15 à 20% par rapport à eAccelerator.

• Activer le cache sur les sites de production est essentiel. La désactivation du cache peut provoquer un ralentissement de l’interface de la boutique d’un facteur de 5 à 6 et une réactivité moindre sous charge.

• Lors de la configuration de Magento Enterprise Edition sur un serveur unique, il est convenable d’utiliser le système de cache par défaut (basé sur le système de fichiers) ou alors APC, qui donne des résultats similaires. Toutefois, en cas d’installation sur des nœuds web multiples, il est préférable d’utiliser  memcached. En effet APC et le système de cache par fichiers requièrent une gestion supplémentaire pour synchroniser les données entre les nœuds.

• L’activation de la fonctionnalité Full Page Caching peut améliorer les performances de Magento Enterprise Edition pour toute page avec du contenu statique (page d’accueil ou autres pages CMS). Ainsi, si vous envisagez d’avoir une page d’accueil statique et que vous utilisez plusieurs pages d’arrivée votre site web, il est fortement recommandé d’activer la fonctionnalité Full Page Caching.

• Dans une configuration à serveur unique, il n’est pas nécessaire de modifier le système de stockage de sessions par défaut (système de fichiers), car il donne les meilleurs résultats. Toutefois, dans un environnement en cluster, si l’équilibreur de charge utilisé ne peut pas associer les demandes des clients avec des nœuds web spécifiques, en se basant sur l’adresse IP ou les cookies du client, il peut être nécessaire d’utiliser soit memcached, soit le stockage de sessions en base de données. Le stockage des sessions dans memcached donne des résultats proches de ceux du stockage par défaut (ou légèrement inférieurs, entre 1 et 2%). Le stockage de session en base de données devrait être utilisé dans un environnement de cluster seulement en dernier recours, dans le cas où le stockage memcached ne pourrait pas être utilisé.

• L’installation du module de Compilation de Magento Enterprise Edition et l’activation de la compilation peuvent donner un gain de performances supplémentaire de 10 à 15%.

• Si vous souhaitez installer et configurer le moteur de recherche Apache Solr, il est recommandé d’activer le support du moteur de recherche Solr dans les options de configuration de la recherche catalogue. La qualité de la recherche augmente de façon significative, même dans le cas où le catalogue est peu fourni, et on peut constater un petit gain de performance (pas plus de 25% sur la navigation catalogue et 14% sur la recherche).

• L’utilisation de processeurs multi-cœurs modernes et de disques durs rapides améliore davantage les résultats. Un serveur simple-cœur, de bas niveau, avec un unique disque dur SATA et 4 Go de RAM installés est capable de traiter environ 9 trans/sec lors des tests sur la page d’accueil et jusqu’à 4 trans/sec au cours d’une session client moyenne. Un serveur dual-core avec un disque dur SATA est capable de gérer 18 trans/sec sur page d’accueil et jusqu’à 7 trans/sec pour des tests d’URL de session client, tandis qu’un serveur 8-core avec des disques durs 15K en RAID1 peut gérer 38 trans/sec sur page d’accueil et environ 17 trans/sec pour des tests d’URL de session client, avec des centaines de sessions simultanées, ce qui permet de prendre en charge plus de chargements de pages pour plus de visiteurs.

Magento Enterprise Edition est la première plate-forme Open Source eCommerce basée sur une technologie solide qui vous donne la flexibilité, la configuration, et les performances dont vous avez besoin pour développer un canal en ligne qui répond aux besoins uniques de votre entreprise.

En prêtant attention à ces détails de configuration qui peuvent être très poussés, et avec quelques réglages minutieux, la solidité, stabilité et performances de  Magento Enterprise Edition vous donnent les moyens de servir de nombreux clients de façon dense et rentable, tout en vous offrant l’avance nécessaire pour vous différencier de vos concurrents… et rester devant eux !

Magento possède un système de cache  avancé qui permet  d’accroitre les performances d’un site tout en limitant les accès à la base de données.

Le contenu des templates s’affiche plus rapidement, la navigation entre les pages est plus fluide, en bref, tout ce qui concerne de près ou de loin au chargement de vos pages s’en ressent  amélioré…

Rappel : Qu’est ce qu’un cache ?

La mémoire cache est une zone de stockage temporaire où les données fréquemment consultées peuvent être stockées pour un accès plus rapide. Une fois les données stockées dans le cache, ces informations peuvent être utilisées par la suite en accédant à la copie en cache plutôt que de ré-extraire ou recalculer les données d’origine.

Cache de Magento

Plusieurs types de cache Magento existent, ils sont ainsi partimentés afin de ne recharger que le strict nécessaire en cas de besoin. Il est donc possible de mettre séparément en cache les fichiers propres à la configuration, le layout, les traductions…

Tous ces caches peuvent être activés ou désactivés directement à partir du backoffice.

Menu : Système > Gestion du Cache

Cache-Magento

Par défaut, Magento stocke ses données périssables telles que son cache et ses sessions à l’emplacement racine du site Magento dans le dossier /var/…, il est donc possible de vider toutes les sauvegardes du cache en supprimant directement les fichiers de ce dossier.

Besoin spécifique : Exemple d’utilisation de Zend_cache

Pour encore plus d’optimisation, il est possible de mettre en cache manuellement certains blocs de Magento dont le temps de chargement est trop long.

- Il est nécessaire de redéfinir un constructeur et de faire un appel à la fonction addData pour prévenir Magento que nous allons ajouter des données au cache.

Trois paramètres sont importants :

• cache_lifetime : Durée de vie du cache (en secondes) -> par défaut il est à 7200 s
• cache_tags : Type de bloc mis en cache
• cache_key : Identifiant de l’ information qui est mise en cache

protected function _construct()

{

$this->addData(array(

‘cache_lifetime’ => 3600,

‘cache_tags’    => array(Mage_Catalog_Model_Product::CACHE_TAG),

‘cache_key’     => $this->getProduct()->getId()));

}

Dans cet exemple, nous voulons réécrire le bloc Mage_Catalog_Model_Product:

”‘cache_lifetime’ => 3600” concerne la durée de mise en cache de l’information (soit 3600 secondes).

”‘cache_tags’    => array(Mage_Catalog_Model_Product::CACHE_TAG) ” concerne l’action qui va déclencher le rafraichissement des données (affichage d’une liste de produits).

”’cache_key’     => $this->getProduct()->getId()));” est l’identifiant du produit qui va être recalculé une fois le temps de mise en cache écoulé et l’action (cache_tags) de nouveau enclenchée.

- La plupart du temps la redéfinition du constructeur n’est pas suffisante, il est donc nécessaire de définir les fonctions séparément, elles feront toutes appel à la classe parent Mage_Core_Block_Abstract-> toHtml().

public function getCacheKey(){}

public function getCacheLifetime(){}

public function getCacheTags(){}

À noter qu’il est également possible d’installer certaines extensions qui mettent en place ces caches comme le cache pour les catégories ou le cache pour les produits. Il est cependant conseillé de les utiliser avec prudence car elles peuvent ne pas apporter entière satisfaction et provoquer plusieurs erreurs au cours de leur installation.

Optimisation du cache

Par défaut, Magento stocke les données propres au cache et aux sessions sur la même partition que le reste des fichiers, donc dans la majorité des cas, sur le disque dur (file system).

Pour optimiser la rapidité d’accès aux fichiers, il est possible de créer une partition RAM, par exemple via Memcached, et y monter les dossiers racine_magento/var/cache et racine_magento/var/session.

Pour activer Memcached dans Magento, il faut ajouter le bloc de code suivant dans le fichier de configuration: /app/etc/local.xml :

<cache>

<backend>memcached</backend><!– apc / memcached / empty=file –>

<memcached><!– memcached cache backend related config –>

<servers><!– any number of server nodes can be included –>

<server>

<host><![CDATA[127.0.0.1]]></host>

<port><![CDATA[11211]]></port>

<persistent><![CDATA[1]]></persistent>

</server>

</servers>

<compression><![CDATA[0]]></compression>

<cache_dir><![CDATA[]]></cache_dir>

<hashed_directory_level><![CDATA[]]></hashed_directory_level>

<hashed_directory_umask><![CDATA[]]></hashed_directory_umask>

<file_name_prefix><![CDATA[]]></file_name_prefix>

</memcached>

</cache>

Attention! Il faut s’assurer que les variables « host » (ici : 127.0.0.1) et « port » (ici : 11211) soient correctes.  Une fois le fichier sauvegardé, les nouveaux paramètres sont tout de suite actifs.

Il existe de nombreuses solutions pour optimiser l’affichage d’un site. Une bonne gestion du cache est l’une d’entre elles. Magento met  à disposition des développeurs une large palette de fonctions qui leur permet d’adapter le code de façon optimum pour chacun de leurs besoins.

Néanmoins, les méthodes présentes par défaut dans l’API Magento ne permettent pas de tout faire, et leur utilisation, dans une démarche organisationnelle d’une société, connaît ainsi certaines limites.
Ainsi, concernant le catalogue produits, il est possible de créer de nouveaux produits, si tant est que l’on reste dans le cadre de produits vendus de manière directe (ce que l’on appelle dans Magento des « produits simples »).
Magento comporte en effet de nombreux types de produits, permettant au marchand d’organiser de manière très souple son catalogue produits :

• Produits simples
• Produits configurables
• Produits groupés
• Produits téléchargeables
• Produits « Bundles »
• Produits virtuels

Grâce aux produits « configurables », le marchand est donc capable de proposer sur son site une unique fiche produit pour un article déclinable en plusieurs combinaisons.

C’est typiquement le cas d’un t-shirt disponible en plusieurs tailles et plusieurs coloris.
Prenons un exemple concret, pour un t-shirt disponible :

• En tailles L, XL et XXL
• En coloris Rouge, Jaune et violet

Du point de vue logistique, le marchand possède un stock de produits relatif à chaque combinaison de valeurs, et donc à chaque référence produit distincte. Il a donc un stock donné pour son t-shirt Rouge taille L, un stock pour le Rouge taille XL, un stock pour le Rouge taille XXL, un stock pour le Jaune taille L, etc…

Dans Magento, pour qu’un produit ait un stock spécifique, il doit avoir une référence spécifique, et doit être un « produit simple ».
On aura donc 6 produits simples dans Magento :

• Rouge / taille L
• Rouge / taille XL
• Rouge / taille XXL
• Jaune / taille L
• Jaune / taille XL
• Jaune / taille XXL

Le marchand ne souhaite pas afficher chaque combinaison de valeurs sur le site (ce qui reviendrait dans notre cas à afficher 6 fiches produits différentes sur le site, pour en fait un même produit, pour lequel seules la taille et la couleur changent…).
Il va donc créer un produit dit « configurable » qui sera le seul affiché sur le site, et qui présentera deux listes déroulantes : l’une pour choisir la taille et l’autre pour choisir la couleur. Pour cela, il crée son produit configurable en BackOffice de Magento, et y rattache les 6 produits simples correspondant aux 6 déclinaisons possibles du produit.

Revenons-en à notre API :
Il est possible, via l’API Magento, de créer ces types de produits, à savoir les produits simples et le produit configurable. Ce qu’il n’est pas possible de faire, c’est de regrouper les produits simples au sein du produit configurable, de sorte que l’on ne peut pas mettre en place (avec l’API standard) des scripts automatiques entre un ERP et Magento qui s’affranchiraient de toute manipulation sur le BackOffice pour regrouper les produits.
Dans le cadre d’un projet pour l’un de nos clients, nous avons ainsi créé une nouvelle méthode que nous avons intégrée à l’API Magento, permettant de faire ce regroupement de produits simples et configurables.

En voici les spécifications :

Objectif
L’objectif est de créer un nouvel outil Webservice permettant de regrouper facilement des produits simples au sein d’un produit configurable. Cette fonctionnalité n’existe pas en standard sur Magento 1.4.0.1.

Description technique
Pré-requis
Pour que la méthode webservice puisse être appelée, les pré-requis suivants doivent être respectés :

• Le produit configurable doit déjà exister (mais sans avoir obligatoirement de produit simple qui lui est relié), dont l’attribut de regroupement est initialisé ou non.
• Le(s) produit(s) simple(s) que l’on souhaite rattacher au produit configurable doi(ven)t déjà exister

Paramètres du webservice

Les paramètres à passer à la nouvelle méthode webservice seront les suivants :

• SKU du produit configurable existant
• SKU du produit simple existant
• Prix spécifique à appliquer (optionnel)
• Règle d’application du prix spécifique (optionnel mais obligatoire si un prix spécifique doit être appliqué)

- « POURCENT » (pourcentage du prix de base)
- « EURO » (nouveau montant en euros)
- Vide si aucun prix n’a été saisi précédemment

• Attribut configurable

Format du webservice
Le webservice suivra le format ci-dessous :
Nom de méthode : catalog_product.assignConfigurable
Retour : Codes de retour suivant résultat
Arguments :

• Chaîne de caractères : SKU Produit configurable
• Chaîne de caractères : SKU Produit simple
• Valeur décimale : Prix à appliquer
• Chaîne de caractères : Valeur prédéfinie parmi « POURCENT » ou « EURO »
• Attribut configurable

Exemples d’appels
Avec prix applicable directement
$proxy-> catalogProductAssignConfigurable(‘sessionId’, ‘skuConfigurable’, ‘skuSimple’, 12.90, ‘EURO’, ‘attribut’);
Avec prix applicable en pourcentage
$proxy-> catalogProductAssignConfigurable(‘sessionId’, ‘skuConfigurable’, ‘skuSimple’, 20, ‘POURCENT’, ‘attribut’);
Sans prix spécifique
$proxy-> catalogProductAssignConfigurable(‘sessionId’, ‘skuConfigurable’, ‘skuSimple’,,, ‘attribut’);

Codes retour
Suivant le résultat de l’action de rattachement du produit simple au produit configurable, plusieurs codes peuvent être retournés :

Spécificités
Le webservice sera développé pour la V2 de l’API Magento, sur la version 1.4.0.1 de Magento. La nouvelle méthode Webservice sera donc intégrée au document WSDL de l’API :
http://www.nomdusite.com/index.php/api/v2_soap/index?wsdl

Les produits configurables initialisés sont créés via l’API Magento et l’(les)attribut(s) de regroupement n’est (ne sont) pas forcément initialisé(s). Le webservice devra donc détecter cela et, si l’attribut n’est effectivement pas initialisé, l’initialiser avec l’(les)attribut(s) donné(s) en paramètre(s). Si le produit configurable est déjà initialisé avec un autre attribut, le webservice retournera une erreur (voir tableau ci-dessus – code retour 6) et l’appel webservice sera ignoré (le webservice ne modifie pas un attribut de regroupement déjà initialisé, il initialise seulement l’attribut au niveau du produit configurable s’il ne l’est pas déjà.

Le webservice vérifie déjà si les attributs de regroupement sont initialisés. Si ce n’est pas le cas, il les initialise avec les attributs passés en paramètre. Ensuite, il lie le produit simple au produit configurable.
Ce type de méthode en webservice peut être également utile dans le cadre des autres produits Magento, notamment les « produits groupés » ou les « produits Bundle ».

Toutes les principales fonctions existent dans Magento. Par exemple, la fonction d’assignation d’un produit simple à un produit configurable est la fonction suivante :
$productConfigurable->setConfigurableAttributesData($dataAttributes)
Il a donc fallu construire le tableau de « super-attribut » $dataAttributes et créer une méthode dans l’API Magento.
Le module est compatible avec Magento 1.4.

Principe

Phing (Phing Is Not Gnu make) est un outil de déploiement permettant d’automatiser une suite d’opérations. Il est comparable à Make (généralement utilisé pour les développements en C et C++) et Ant (le plus souvent utilisé dans le cadre de développements en Java). Comme ces deux outils, il permet de définir une série de tâches à accomplir et des dépendances entre ces tâches. Sur beaucoup de points, Phing ressemble à Ant sur lequel il est basé directement.

Phing est un outil programmé entièrement en PHP, développé en open source (Gnu Lesser General Public License). Toute la documentation, et le code source sont disponibles sur le site suivant : http://www.phing.info/trac/

Installation

L’installation de Phing est très aisée, que ce soit sur Linux ou Windows : elle se fait en utilisant le package manage  Pear :

pear channel-discover pear.phing.info
pear install phing/phing-beta

Nous avons également installé l’extension pour utilisation native de SVN :

pear install VersionControl_SVN-0.3.3

Dans notre cas, il a aussi été nécessaire d’installer SSH2, la librairie PHP permettant de se connecter en SSH :

pecl install SSH2-0.11.0

Utilisation

Phing est un outil en ligne de commande, qui s’appelle simplement en tapant la commande :

phing

Si l’on veut exécuter une tâche particulière, il suffit de la spécifier de cette façon :

phing <task name>

Fonctionnement

Lorsque phing s’exécute, il va chercher le fichier ‘build.xml’ à l’emplacement du dossier courant, et exécute la tâche spécifiée ou la tâche par défaut du fichier.

Le fichier build.xml est un fichier xml de ce type :

<?xml version=”1.0″?>
<project name=”build” default=”main”>
<property value=”.” />
<property value=”svn” />
<target depends=”update-back”/>
<target>
<svnupdate
svnpath=”${svn_path}”
todir=”${project_root}”
nocache=”true” />
</target>
</project>

Le tag project définit le projet, la propriété default est le nom de la tâche appelée par défaut.

Les tags ‘property’ correspondent à des variables. La propriété name en est le nom, et value la valeur. Il peut s’agir de chaines de caractères, ou de listes de chaines de caractères séparées par une virgule.

Les tags ‘target’ correspondent à des tâches. La propriété name est le nom d’appel de la tâche. La propriété depends est la liste des autres tâches à exécuter avant la tâche courante. A l’intérieur du tag, les autres tags sont la liste des commandes à exécuter par le script. Pour la tâche update-back par exemple, il s’agit d’un svn update.

Il existe un certain nombre de commande exécutables par défaut :

exec : exécute une ligne de commande

foreach : parcours un tableau et pour chaque élément renvoie vers une autre tache avec l’élément en argument

et différentes autres : chmod, chown, delete, move, etc. La documentation complète est disponible ici : http://phing.info/docs/guide/trunk/

Usage sur un projet spécifique PHP/Symfony

Choix de Phing

Phing a été choisi, plutôt que Ant ou Make pour une raison principale : c’est un outil fait en PHP. Cela apporte les gains suivants :

• Facilité d’utilisation pour une équipe PHP
• Pas besoin d’installer Java ou d’autres utilitaires sur nos serveurs
• Possibilité d’écrire du code PHP directement dans une tâche si nécessaire
• Possibilité d’étendre l’outil en créant de nouvelles tâches en cas de besoin

Tâches disponibles

Les tâches suivantes on été créées dans le cadre de notre projet. Toutes ont été écrites pour être appelées depuis le serveur de backend. Le fichier build.xml est présent sur le serveur de backend, et est dans svn à la racine de la branche de production.

Celles-ci ont été écrites pour être appelées par des tâches principales, elles ne devraient pas être appelées individuellement :

update-back : update la copie locale du backend

rollback-back : revert la copie locale du backend jusqu’à la révision spécifiée

clear-backend-cache : vide le cache symfony du backend

update-filer : update la copie locale du filer

rollback-filer : revert la copie locale du filer jusqu’à la révision spécifiée

clear-frontend-cache : vide le cache symfony des serveurs frontaux

Celles-ci sont les tâches principales, qui peuvent être appelées directement :

main : (tâche par défaut), elle appelle update-back, update-filer et clear-backend-cache. Elle permet d’effectuer une livraison sans risque sur les frontaux – mais dont les effets ne pourront peut-être pas être vus immédiatement car les caches ne sont pas vidés.

cc : elle appelle main et clear-frontend cache. Elle sert à effectuer une livraison avant 9h.

rollback : elle prend en argument une révision, et appelle les tâches rollback-back, rollback-filer et clear-backend-cache. Elle permet de faire un retour arrière sans risque sur les frontaux – mais dont les effets ne pourront peut-être pas être vus immédiatement car les caches ne sont pas vidés.

rollbackcc : elle prend en argument une révision, et appelle les tâches rollback et clear-frontend-cache. Elle sert à faire un retour arrière avant 9h.

Gain par Phing

Phing a été mis en place il y a une semaine. Les gains déjà visibles sont :

• Facilité des déploiements, moins fastidieux
• Sécurité des déploiements : plus de problème d’oubli d’un update ou d’un vidage de cache
• Rapidité des déploiements : 30 secondes d’opération au lieu de plusieurs minutes
• Maintien de la simplicité des déploiements en cas d’évolution de l’architecture système (par exemple, lors de l’ajout d’un frontal, il suffit d’ajouter son IP dans la liste des frontaux, et le processus de déploiement reste valide)

Evolutions futures

Phing est un outil extrêmement flexible, voici quelques évolutions possibles de son utilisation :

• Passage de tests automatiques dans la foulée du déploiement pour le valider
• Automatisation des évolutions de base de données en utilisant les outils symfony appropriés
• Validation de l’absence de conflit SVN lors du déploiement