Retour d’expérience : il était une fois le Continuous Delivery chez Meetic

Les 7 et 8 avril 2014 a eu lieu le Symfony Live 2014, et ce fut pour mon compère Joris Calabrese (@jorisCalabrese) et moi l’occasion de présenter lors d’un lightening talk notre retour d’expérience sur la mise en place du Continuous Delivery chez Meetic (que je remercie ici publiquement de me permettre de payer mes factures chaque mois :))

Les slides de la présentation sont disponibles sur Slideshare pour ceux qui voudrait y jeter un oeil et voir comme on a relevé le défi de fluidifier nos projets (et dans une DSI de 150 personnes, et des équipes produits nombreuses, ça n’a pas été du gâteau, croyez-moi).

http://fr.slideshare.net/jorisCalabrese/continuous-delivery-chez-meetic (Le design est de Joris qui a fait un travail de dingue sur ces slides).

Publié dans Intégration continue, Kanban, Organisation

Hack : Facebook montre à PHP son retard

hackCoup de tonnerre dans le Landerneau de PHP : Facebook, après avoir sorti HipHop pour exécuter PHP en mode compilé, après avoir sorti HHVM et son compilateur à la volée, passe la seconde et propose son fork de PHP avec de nombreuses évolutions par rapport au langage original.

Comme je l’avais déjà indiqué dans un billet précédent, il y avait plus urgent à ajouter dans PHP qu’une API pour les passwords ou les générateurs. Et là, j’avoue avoir l’eau à la bouche.

Hack (car c’est son petit nom si affectueux) nous propose :

  • Un grand coup de balai dans les vieilleries et autres mauvaises pratiques du langage (genre les globals !)
  • Du typage un peu plus fort (pas du luxe)
  • Un peu d’asynchronisme
  • Des génériques (enfin pouvoir avoir des Array<Machin>)
  • Des collections
  • etc.

Bref, sur le papier ça donne vraiment envie, et on peut compter sur Facebook pour fédérer une communauté. Voilà ce que devrait être PHP 6.

En tout cas, j’ai hâte de voir ce qu’on peut en faire. Alors voilà, c’est pas que je m’ennuie avec vous, mais je vais de ce pas monter un HHVM et faire joujou avec.

Des news bientôt !

Publié dans Hack, PHP

LiipDoctrineCache : Utiliser une ferme multi-serveur Memcache

Quand comme moi vous travaillez dans une société qui a besoin de haute-disponibilité (ce qui correspond à la grosse majorité des entreprises dans le web, non ?), vous ne pouvez pas dire :

Mon cache, je le stocke sur un serveur unique qui peut claquer à tout moment.

Du coup, si vous utilisez Memcache, il vous faut au moins 2 serveurs pour répartir vos clés de cache (avec ou sans redondance).

Vous pourriez très bien me rétorquer :

Hey mec, c’est que du cache ! S’il est down, le site continuera de fonctionner.

Sauf que l’on sait tous ce que peut donner un site sans cache, surtout si ce dernier faillit en pleine période de pointe (ce qui est plus que probable connaissant ce sadique de Murphy).

Et si comme moi vous avez adopté le bundle LiipDoctrineCacheBundle, qui permet d’utiliser les classes de cache de Doctrine (utilisées par l’ORM à l’origine, mais qui fonctionne très bien aussi en autonome).

Mais voilà : dans la configuration offerte par le bundle, seul un couple host/port n’est possible.

Heureusement, il est possible d’utiliser le paramètre « id » qui permet de faire référence à un service du conteneur d’injection. Du coup, vous pouvez placer dans le conteneur un service Memcache configuré avec votre ferme de serveurs, et le passer à la configuration « liip_doctrine_cache »

Exemple :

services:
    my_memcache_farm:
        class: Memcache
        calls:
            - [ addServer, [ "serveur1", 11211 ] ]
            - [ addServer, [ "serveur2", 11211 ] ]

liip_docrine_cache:
    namespaces:
        my_namepace:
            type: memcache
            id: my_memcache_farm

Et le tour est joué : votre configuration multi-serveur memcache peut ainsi être utilisée avec Doctrine cache.

Vous pouvez aussi en profiter pour positionner les timeouts de connexion et de réponse des serveurs.

Point fort supplémentaire : si vous utilisez la même ferme de cache pour plusieurs namespaces, vous n’avez pas à dupliquer autant de fois la configuration.

Maintenant, si vous avez du temps pour tester, l’utilisation de Couchbase permet d’amener en plus la redondance et une meilleure répartition des données sur les noeuds, la suppression de noeud à chaud, etc… J’ai hâte de tester et de vous dire tout ce que j’en pense de bien (ou pas)

Publié dans PHP, Symfony2

Ce qu’il me manque vraiment dans PHP

DISCLAIMER : je suis en mode grosse mauvaise foi ce soir, mais si ça peut donner des idées…

PHP est un langage que j’aime beaucoup. Je l’utilise depuis plus de 10 ans maintenant, et dans ce laps de temps, il a énormément évolué.

J’ai connu un langage de script facile à utiliser, mêlant  à l’époque le code et le HTML (je sais, on ne fait plus ça maintenant, mais j’étais jeune et innocent…).

La version 5 a amené un modèle objet qui tenait enfin la route. Ne serait-ce que les accesseurs et la différentiation entre méthodes statiques et d’instance ont donné un énorme confort d’utilisation et une limitation des erreurs d’utilisation des librairies par des clients.

Malheureusement, depuis 2 versions, j’ai la nette impression que les ajouts faits au langage sont plus du cosmétique.

  • PHP 5.4 : principalement de la syntaxe avec la notation courte des tableaux, la possibilité d’appeler des méthodes sur une instance anonyme créée, ou la dispo de <?= même si les short_open_tags sont désactivés. (Bon OK, il y a les traits aussi, mais je n’aime pas trop ce type de structure qui nuit à la lecture du code à mon avis)
  • PHP 5.5 : une nouvelle API pour gérer les mots de passe (euh… je faisais très bien sans en fait), le mot clé finally (OK, celui-ci est plutôt utile), et opcache (plutôt une extension et les générateurs (pratiques, mais pas révolutionnaires non plus)
  • PHP 5.6 va sans doute proposer une possibilité de gérer des fonctions variadics (avec un nombre variable d’arguments) par exemple.

Je sais, je suis de mauvaise foi, car chaque version apporte une évolution en terme de performance, et, de plus, il y est fait un gros nettoyage d’un certain nombre de mauvaises idées (comme le safe-mode) ou fonctionnalités obsolètes (comme les fonctions ereg*).

Mais est-ce vraiment ce qui nous bloque le plus ? J’aurais tendance à dire que non (mais je suis peut-être le seul à le penser bien sûr).

Ce qui me manque le plus, c’est un vrai contexte d’application, et pas seulement une capacité de persister un contexte réutilisable facilement (comme dans un memcache par exemple). Une zone dans laquelle on pourrait gérer un vrai pool de connexion aux bases de données (à la manière des datasources de Java), et ceci faciliterait aussi la gestion des connexions persistentes aux bases de données (en cas d’indisponibilité temporaire, ou en cas de bascule automatique sur une standby par exemple).

Pour avoir ce genre de système de manière efficace, il faut en général se tourner vers Java, mais quand de grandes sociétés ont basé leur stratégie de développement sur un langage, il est toujours difficile d’ajouter un nouveau larron dans le SI (même si une architecture basée sur les principes de la SOA peut faciliter cette transition bien sûr). De plus, la JVM apporte une complexité d’exploitation pour les ops et la nécessité de maîtriser les arcanes du garbage collector.

J’avoue ne pas avoir le début du commencement d’une idée sur la manière de gérer ce point de manière efficace… sans doute en utilisant un nouveau type de SAPI, ou faire évoluer APC… mais avouer que ce serait top, non ?

Allez ! Je me le note sur ma liste au père noël pour l’an prochain… et pourquoi pas essayer de le faire si j’arrive à me dégager un peu de temps.

Publié dans PHP

Améliorer le warmup du cache de Symfony2

Lorsque vous vous lancez sur un développement sous Symfony2 en venant d’un monde sans framework (oui, je sais, cela peut surprendre mais il existe encore quelques peuplades reculées qui résistent encore et toujours à l’envahisseur), un des challenges à surmonter est la gestion du cache du framework lors du déploiement d’une application. Si en plus cette application est utilisée par des milliers d’internautes en Europe, le moindre à-coup dans les performances peut être difficile à vivre par votre plate-forme.

Cache warmup

Une chose à ne pas oublier quand vous déployez une nouvelle version de votre application est de « préchauffer » (warm-up) le cache du framework.

Eh oui, un peu comme les moteurs diesel des années 80 !

Par contre, si le framework monte déjà beaucoup de choses, il manque une petite chose qui peut vous permettre de ne pas avoir des temps de réponses moisis au moment de la bascule : la chauffe du fichier classes.php

A quoi sert ce classes.php  ?

Afin d’éviter de passer son temps à faire appel à l’autoload pour toutes les classes qui servent souvent, le framework génère un fichier contenant un certain nombre de classes, le charge en une fois au boot du kernel.

Cependant, ce fichier met un certain temps à être généré par les premières requêtes qui arrivent sur votre pauvre application sans défense tout juste sortie de son nid. Et comme les internautes voraces veulent tous en même temps des réponses à leurs requêtes, les premiers arrivés se retrouvent tous à calculer cet unique fichier.

Heureusement il y a les CacheWarmer (warmeeeeeeeer !)

Symfony2, dans son infinie sagesse, offre la possibilité au développeur avisé d’ajouter des bouts  de code permettant de chauffer le cache pour ses besoins spécifiques.

Comment ? En ajoutant à vos bundles une classe implémentant l’interface CacheWarmerInterface, en la déclarant comme service dans l’injection de dépendance et en le tagguant (gentiment  !) comme kernel.cache_warmer.

Et comme je suis gentil, le warmer de classes.php, je vous l’offre ! Le code de ce bundle est sur Github bien sûr et il est disponible sur packagist évidemment.

1. Ajouter le à votre composer.json

{
    "require" : {
        "zibok/class-cache-warmer": "dev-master"
    }
}

2. Ajouter le bundle dans votre AppKernel

new Zibok\Bundle\ClassCacheWarmerBundle\ZibokClassCacheWarmerBundle();

Et le tour est joué : vider votre cache et vérifier que dans le nouveau répertoire vous avez bien le classes.php.

Conclusion

Au delà de l’aspect (un peu) pratique de ce bundle, il est également un exemple très simple de cache warmer que je vous invite à lire si vous êtes novice pour vous rendre compte à quel point il est facile de venir se greffer à la gestion/génération du cache de Symfony2.

Publié dans Symfony2