technique @PMSIpilot

Blog du service technique de PMSIpilot

nov

7

Agile Barcamp Lyon : Kanban

By Serv-Tech

Je connais la méthode Scrum, pour en pratiquer une partie dans mon équipe, et j’étais intéressée par l’approche Kanban, qui n’est pas itérative avec des sprints isolés comme Scrum, mais qui prend en compte les arrivées en cours de route (les bugs, par exemple) et permet de les intégrer au flux. (Nous traitons ces demandes entrantes dans nos sprints en utilisant la focalisation.) De plus, mon envie de découvrir Kanban a été récemment augmentée, surtout à travers un retour d’expérience, car je suis passée à un travail de maintenance qui peut se faire sans sprint.

Généralités

Kanban signifie étiquette en japonais. C’est une méthode que Toyota a utilisé dans ses usines. Elle consiste à utiliser des caisses étiquetées pour mesurer leur trajet, et ainsi la production. Les étiquettes étant toujours attachées à leur caisse, ce qui permet de tracer leur parcours.

Les principes de Kanban sont de mesurer le Work In Progress (ou en-cours) et de le limiter. En appliquant à un travail informatique, on observe 3 valeurs (et leur évolution) sur notre tableau de bord :

  • le reste à faire
  • l’en-cours
  • le réalisé

On garde à l’esprit que plus on a d’en-cours, moins notre réactivité sur le travail entrant (reste à faire) est bonne.

Principes

Les principes de Kanban sont donc :

  1. limiter les en-cours
  2. produire just-in-time
  3. tiré par la demande

Vous trouverez les principes plus complets sur le site : http://chohmann.free.fr/lean/kanban.htm

Un exemple industriel de Kanban est le Kanban Double Bac. Il s’agit d’avoir, sur une chaîne de montage, un opérateur qui a, pour ses petites pièces (ex: des boulons), 2 bacs de stock. Il se sert dans un seul bac à la fois, par exemple il commence par le bac A, et quand le bac A est vide, il permute avec le bac B (encore plein).
Un logisticien vient alors chercher le bac A vide, le remplace par un bac C plein, et note qu’il a rempli un bac.

Voici comment est décrit le process dans Wikipedia :

Le système Kanban fonctionne entre les postes de production aval et amont :

  • L’opérateur aval entame un conteneur. Il libère alors le kanban de manutention fixé sur le conteneur et le dispose dans une boîte,
  • Le manutentionnaire ramasse le kanban de manutention et va au poste amont,
  • Au poste amont, il enlève le kanban de production du conteneur plein, le met dans une autre boîte et lui substitue le kanban de manutention,
  • Il ramène le conteneur plein avec le kanban de manutention au poste aval,
  • Quand l’opérateur du poste amont a rempli un conteneur, il regarde la boîte de kanbans de production. S’il y a un kanban, il l’enlève, le fixe à un conteneur vide et reprend la production. S’il n’y a pas de kanban, cela veut dire que les en-cours sont suffisants et il attend.

Un exemple de flux de travail en mixant Kanban et Scrum a été donné par Alain, qui vient de la même boîte que Christophe Ney (vous retrouverez la présentation avec des images de ce qui a été mis en place sur Slideshare http://www.slideshare.net/cney/scrum-et-kanban-agile-grenoble-2011).

Ce que j’en ai retenu

On considère alors le sprint comme unité qui passe dans le Kanban. L’exemple utilise 3 lignes de production (qui chacune ont préparation – production – livraison comme phases) :

  • sprints : préparation de sprint, réalisation du sprint, revue de sprint
  • maintenance (TMA), qui peut être de la correction de bug, mais qui peut également être une réunion
  • non-planifié (prioritaire) : date fixe et proche

L’équilibre à trouver est le rapport en l’en-cours et le stock (le reste à faire) : on met du temps à savoir combien il nous en faut en stock et combien on peut en avoir en cours de manière concurrentielle.
Au sein du travail en équipe, les stand-up meeting Kanban sont focalisés sur les tickets plutôt que sur les gens : on fait donc le tour des tickets (des post-it chez nous), plutôt qu’un tour de parole des gens. C’est très intéressant avec une équipe nombreuse.
L’idée avec Kanban est de travailler en continu, en flux tendu. Kanban permet de mesurer la production pour trouver son rythme (ratio entre encours et entrant).

Voilà ce qui est indiqué sur les étiquettes du système mixte Kanban / Scrum :

  •  date de début
  • date de livraison prévue
  • trigramme des personnes capables/préssenties pour la réalisation
  • nom du ticket et détails

Les limites

Les limites de Kanban, citées par Christophe Ney sont :

  • le stock (à faire) est trop important par rapport à l’en-cours qui a atteint sa limite
  • le champ de vision du flux est sur quelques semaines seulement
  • les opérations à date fixe (ex : un site de Noël pour agence web, avec une date de péremption) ne rentrent pas bien dans le système Kanban

août

20

Utilisation de Jenkins à PMSIpilot

By Serv-Tech

Nous allons, au cours de cet article, tenter de présenter l’utilisation de l’intégration continue (avec Jenkins) au sein de PMSIpilot ainsi que les problèmes que nous avons rencontré lors de sa mise en place.


Introduction

Au sein de l’équipe de développement à PMSIpilot, le workflow fonctionne ainsi :

  • une branche contenant la future version majeure (branche “master”)
  • une branche stable : les corrections de bugs y sont effectuées, puis backportées sur le master
  • 2 branches d’équipe : chaque développeur va merger (intégrer) ses branches de fonctionnalités sur la branche d’équipe, qui sera ensuite mergée dans le master.
  • des branches de fonctionnalités : chaque fonctionnalité donne lieu à une branche, celle-ci peut partir soit de la branche stable ou d’une des branches d’équipe. Celles-ci sont testées localement sur le poste du développeur avant d’être réintégrées sur la branche de départ.

 

De nombreux tests sont effectués, dont certains prennent plusieurs heures. Ces tests sont :

  • des tests fonctionnels (utilisant le sfTestBrowser de symfony)
  • des tests unitaires (utilisant lime)
  • des tests d’intégration (utilisant lime) : où l’on vérifie le comportement de l’utilisation de plusieurs classes entre-elles, ou l’on effectue des imports de données et vérifie le contenu de celles-ci en base, ou passe une mise à jour et vérifie que celle-ci fonctionne correctement.


Le projet est versionné sous Git qui, une fois cloné, occupe 11Go d’espace disque. Cela a donc causé plusieurs problèmes qui ont nécessité diverses adaptations sur la plateforme d’intégration continue (un Jenkins que nous utilisons depuis maintenant plus de 2 ans.)


DOS sur srv-git à cause du nombre de jobs

Le dépot Git du projet PMSIpilot est hébergé en interne (sur un serveur qu’on appellera par la suite srv-git).
Peu après la migration de Subversion vers Git, de nombreux jobs se terminaient avec cette erreur :

remote: fatal: Out of memory, malloc failed
error: git upload-pack: git-pack-objects died with error.
fatal: git upload-pack: aborting due to possible repository corruption
 on the remote side.
remote: aborting due to possible repository corruption on the remote side.
fatal: early EOF
fatal: index-pack failed

En effet, tous les jobs étaient lancés à 18h, et le fait d’avoir trop de clones en même temps posait des problèmes de mémoire.

 

 

Un repack régulier du dépôt a corrigé ce problème lorsque l’on clone le dépôt sur nos postes (http://www.kernel.org/pub/software/scm/git/docs/git-repack.html), mais le problème subsistait sur hudson.

 

Pour éviter cela nous avons donc limité le nombre de clones effectués en même temps en n’effectuant qu’un clone par esclave :

  • On a donc un job qui va cloner le dépôt en local sur chacun des esclaves et sur le maître.
  • Celui-ci est appelé à chaque push Git effectué sur srv-git.
  • Tous les autres jobs “clonent” le dépôt depuis le clone local.

 

 

Lancement des tests à chaque push

Bien que certains tests soient longs à s’exécuter, d’autres sont rapides ou sont souvent risque d’erreur. Ces tests sont donc lancés à chaque push sur le dépôt.

Comme vu précédemment, pour régler des problématiques de charge, nous avons un job Jenkins qui va cloner/mettre à jour le dépôt se trouvant en local sur la machine exécutant les tests.

Nous sommes donc ici confronté à un problème : comment être sûr que le dépôt est à jour avant de lancer les tests ? Le “Join plugin” (https://wiki.jenkins-ci.org/display/JENKINS/Join+Plugin) va nous permettre de répondre à cette problématique.


A chaque push effectué sur le dépot :

  • un job appelé “post-receive” est appelé,
  • celui-ci va déclencher les mises à jour des clones locaux des dépots git sur l’ensemble des machines de test
  • Une fois que ceux-ci seront terminés (et c’est grâce au Join Plugin que l’on peut appliquer cette condition), les jobs de test seront lancés, et ce, en étant sûr que la dernière version se trouve bien sur le clone local.

 

Problème de taille du dépôt.

Une fois cloné, notre dépôt Git prend plus de 10,6Go dont plus de 8,2Go de .git.

Notre serveur d’intégration continue contient beaucoup de jobs, nous avons donc cherché un moyen de gagner de la place, les disques utilisés n’étant pas suffisants pour faire tourner les jobs sur toutes les branches.

Pour cela il existe l’option –shared sur le git clone qui permet de partager les objets du .git entre le dépôt cloné et le dépot clonant (sous réserve que le clone soit local, que le dépôt cloné soit sur le même système de fichier).

En utilisant cette option lors d’un git clone, cela permet de gagner de l’espace disque, en limitant l’occupation de chaque job à 2,4Go.

Cette option ne se trouvant pas dans celles (du clone) du plugin Git pour Jenkins, nous avons donc ajouté celle-ci au plugin, effectué une pull request (https://github.com/jenkinsci/git-plugin/pull/21) et, en attendant, nous utilisations une version patchée du plugin Git pour Jenkins. La pull request n’a pas été acceptée car un refactoring du plugin était prévu pour permettre plus de généricité dans ces options (il n’a depuis, toujours pas été effectué). Nous utilisons donc toujours notre version patchée.


Plusieurs jobs avec une configuration identique

Comment indiqué précédemment, à PMSIpilot notre workflow fonctionne avec plusieurs branches :

  • une branche stable
  • une branche contenant la future version majeure (master)
  • 2 branches d’équipe
  • une branche par feature


Il faut donc pouvoir tester ces branches (le testing des branches de features sera développé dans la suite de l’article).

Pour cela nous avons dupliqué tous les jobs en modifiant la branche utilisée.

Cela permet de les lancer parallèlement et d’avoir un historique plus lisible, celui-ci étant tout le temps sur une même branche.

Cela pose un problème de cohérence des jobs. En effet certains jobs peuvent avoir été configurés d’une certaine manière sur une branche et pas sur une autre, nous avons donc un job vérifiant que la configuration des jobs est identique selon les vues, à l’aide d’une convention de nommage des jobs qui simplifie leur création (projet-branche-test).

Nous dupliquons les jobs et n’utilisons pas les jobs multi-configuration car ceux-ci ne permettent pas d’avoir en un coup d’oeil le statut des jobs pour une configuration donnée.

Cette duplication n’est pas seulement utile pour tester des branches mais nous a aussi servi à tester des environnements différents. Le projet utilisait php 5.2 et nous avons récemment effectué une migration vers php 5.3. Pendant environ un an, nous avons eu une vue contenant l’ensemble des jobs utilisés par nos tests, mais exécutés sur un esclave avec notre mise jour en php 5.3 effectuée. Au départ il y avait plusieurs tests à corriger car ne fonctionnant pas en 5.3 et, ensuite, une fois corrigé, elle a permis de valider que les nouveaux développements fonctionneraient après migration.

 

Pour simplifier la création de ces branches ou modification de celles-ci nous avons donc créé quelques commandes qui permettent d’automatiser certaines tâches :

  • Copie des jobs d’une vue
  • Suppression de tous les jobs d’une vue
  • Changement de branche pour toute une vue.


Nous avons pour cela utilisé une bibliothèque développée dans le cadre du projet Jenkins-Khan : https://github.com/pmsipilot/jenkins-php-api qui permet d’utiliser facilement l’api de Jenkins en PHP.


Ces tâches servent par exemple lors de la sortie d’une nouvelle version. Les jobs du master seront copiés et la branche utilisée sera modifiée (en effet, il faut repartir de la vue master, la configuration des jobs ayant pu changer, ou de nouveaux jobs peuvent avoir été ajoutés). Ensuite les jobs de l’ancienne version stable seront supprimés ainsi que toutes les bases de données et workspaces liées (lors de la suppression d’un job, Jenkins ne supprime que le workspace du job se trouvant sur le maître, et pas ceux se trouvant sur les esclaves.


Testing des branches de feature

Nous avons tout d’abord mis en place un Jenkins en local sur chaque poste de développeur avec l’ensemble des jobs se trouvant sur le Jenkins exécutant les tests tous les soirs.


Ces jobs avaient la particularité d’être paramétrés avec un paramètre BRANCH. Ainsi, lorsqu’on lançait un job, la branche que l’on voulait tester était demandée par Jenkins et les tests se lançaient sur cette branche. Le dépôt configuré étant le chemin vers le dépôt local du développeur.

Cela permettait d’exécuter des tests parfois très longs (plusieurs heures), en local, avant de merger dans la branche d’équipe, sans monopoliser le workspace de développement.

Mais cela posait un problème à l’utilisation. On ne pouvait pas facilement voir l’état d’une branche. Nous avons donc ajouté quelques commandes à notre outil pflow https://github.com/pmsipilot/pflow permettant de voir le statut d’une branche.

Nous avions par exemple une commande permettant de voir l’état d’une branche :

>pflow jenkins show

-!- symbolic-ref HEAD
Tests on branch : ticket_23544
autoload FAILED
cache UNTESTED
credential_map UNTESTED
deversement_par_annee PASSED
divers UNTESTED
filtres RUNNING
import-ext UNTESTED
import-had UNTESTED
import-ssr UNTESTED
patchs UNTESTED
qualifact-divers FAILED
requeteur UNTESTED
sansMulti-cdg UNTESTED
sansMulti-externe UNTESTED
sansMulti-had PASSED
sansMulti-mco UNTESTED
sansMulti-ssr UNTESTED
sauvegarde-globale UNTESTED
scenarios-cdg UNTESTED
unit UNTESTED
unit_db_fs UNTESTED

 

Ainsi qu’une autre pour lancer les tests “pflow jenkins launch” lançant l’ensemble des jobs pour une branche.


Mais ces commandes étaient peu utilisées, et ne permettaient pas d’avoir une liste de branches testées, avec leur statuts. Il fallait le vérifier manuellement.
C’est pour ces raisons que Jenkins-Khan a été développé.
Plus d’informations peuvent être trouvées à ce propos sur l’article lui étant dédié.

http://www.pmsipilot.org/2012/05/14/jenkins-khan-faciliter-la-validation-par-branche-via-jenkins/

 

Travail d’équipe avec Jenkins

Historiquement seulement 2 personnes vérifiaient quotidiennement le statut des jobs sur Jenkins, et répartissaient les correctifs à effectuer aux différents développeurs ayant éventuellement cassé le build.

Cela ne permettait pas de partager la connaissance sur les différents tests effectués, ni d’impliquer l’équipe dans le testing.

Nous avions déjà une personne, changeant chaque jour, qui anime le morning meeting (donne la parole et renseigne le niko-niko).

Maintenant cette personne est aussi “responsable Jenkins” pour la journée et va être chargée de savoir pourquoi les tests ne passent plus ainsi que de répartir les correctifs à effectuer aux personnes concernées.

De plus, chaque job ne passant pas est notifié sur un salon jabber qui est alors vu par l’ensemble de la technique.

Quelques chiffres

  • notre Jenkins contient un total de 207 jobs
  • ceux-ci prennent 322 heures à s’exécuter (si lancés séquentiellement)
  • La durée moyenne d’un job est d’une heure et demie, avec une durée maximum de 15 heures.
  • 4 branches du projet sont testées toutes les nuits.
  • Environ 38 jobs sont associés à chaune de ces 4 branches
  • les tests d’une branche prennent au total 95 Heures.
  • 4 esclaves ayant chacun 4 slots sont utilisés
  • 2 disques de 600G en RAID0 sont utilisés sur chaque esclave Jenkins
  • les jobs en occupent 64%, c’est à dire 653G

Plus d’informations sur les tests unitaires peuvent être retrouvées ici :
http://www.pmsipilot.org/2012/06/14/2-ans-de-tests-unitaires/

 

Plugin utilisés

Pour finir voici quelques-uns des plugins installés :


Bilan

Notre Jenkins nous permet d’être réactifs en cas de régression (aussi bien lorsqu’elles arrivent en cours d’ajout de fonctionnalités, que pour permettre de sortir des mises à jour correctives relativement rapidement).

Il nous a fallu beaucoup de temps pour que celui-ci soit assez stable, et que les tests ne passant pas soient corrigés le plus rapidement possible. Cependant le workflow mis en place et les bonnes habitudes permettent de faire en sorte que les jobs ne passant pas plus d’une demi-journée soient des exceptions.

Il reste de nombreux axes d’amélioration, un des plus gros étant la durée des tests. En effet certains tests prennent plus de 10 heures à s’exécuter, ce qui bloque parfois le merge de certaines fonctionnalités.

De plus certains tests sont parfois difficiles à débogger sans l’aide de la personne ayant écrit le test. Un travail sur les logs ainsi que la documentation serait à effectuer.

Du coté des tests fonctionnels, ceux-ci sont effectués via le sfTestBrowser de symfony qui nous permet de valider le contenu de la plupart des tableaux de bord de nos applications. Mais celui-ci a ses limites (tests cross-applications sont lourds à écrire, pas de test sur le JS executé coté client), qui nous pousse à nous tourner vers des frameworks de BDD tels que Behat (http://behat.org/).

Enfin, du travail reste à faire sur la maintenance de certains tests unitaires pour améliorer l’injection de dépendance ainsi que la lisibilité des tests. Le testing procédural de lime rend ceux-ci peu lisibles, maintenant que le projet est passé en php 5.3, il nous serait possible de migrer vers un framework de test plus moderne, par exemple atoum (https://github.com/mageekguy/atoum).

juin

14

2 ans de tests unitaires

By Serv-Tech

Cela va maintenant faire deux ans que, chaque semaine, nous conservons quelques métriques à propos des tests unitaires et de leur couverture. En voici quelques-unes :

  • En deux ans la couverture des tests unitaires est passée de 11% à 31%.
  • Depuis février 2011, les tests unitaires sont découpés en deux : unit et unit_df_fs. Les deux jobs différents nous permettent de séparer les tests unitaires faisant appel à la base de données et au filesystem des autres. A cette époque, le pourcentage de tests unitaires était seulement de 57%, il est maintenant à 74%.
  • Il y a 1189 tests unitaires (avec 9511 test case)
  • Il y a 512 tests unit_db_fs (avec 4592).
  • Il y a deux ans, le nombre de tests était de 263. Il y en a maintenant 1601.

Couverture des tests unitaires en nombre de lignes

Au sujet du nombre de lignes, en juin 2010, il était de 207 260 pour un total de 24 268 lignes couvertes. En juin 2012, il est de 444 463 lignes pour 138 737 lignes couvertes. Là où le nombre de lignes total a subit une augmentation de 114%, le nombre de lignes couvertes a augmenté de 471%. La couverture des tests unitaires a donc augmenté plus vite que le nombre de lignes totales.

Couverture des tests unitaires en nombre de méthodes

On peut voir sur le graphique ci-dessous que le nombre de tests évolue en même temps que le nombre de subtests. Mais, depuis quelques temps (fin 2011), le nombre de subtests évolue plus vite que le nombre de tests. Il y a donc plus de cas de testés pour chaque test.

Nombre de tests et subtests

Un autre indicateur conservé (celui-ci depuis décembre 2010) est le nombre d’erreurs de conventions présentes sur le projet. Celui-ci à beaucoup varié, de 3508 erreurs en 2010 on est passé à 2190 erreurs de conventions. La mise en place d’un hook de pré-commit à permit limiter celles-ci et de les corriger au fur et à mesure. La montée en aout 2011 apparaît suite au merge d’une branche de refactoring n’effectuant pas ces contrôles.

Nombre d'erreurs de convention de codage

Tous ces métriques sont bien-sûr là à titre indicatif, le but n’étant pas forcément d’obtenir une couverture du code à 100%.

mai

14

Jenkins Khan : faciliter la validation par branche via Jenkins

By Serv-Tech

Avant de rentrer plus dans les détails de Jenkins Khan, voici notre workflow lorsque nous travaillons sur une nouvelle fonctionnalité / un correctif :

  • création d’une branche de travail à partir de la branche stable,
  • réalisation du développement,
  • validation du développement en exécutant les tests sur la branche de travail,
  • merge de la branche de travail sur la branche stable.

À PMSIpilot, nous utilisons Jenkins pour notre intégration continue et l’exécution des tests de validation techniques. Chaque développeur a, sur son poste, une instance de Jenkins branchée sur son dépôt.

Il est vite apparu que le rendu de Jenkins, dont l’interface est plus orientée vue “par job”, ne convenait pas dans le cadre de la validation de nos développements. C’est là où Jenkins Khan intervient, en nous fournissant une interface orientée vue par branche afin de suivre la validation.

En cumulant les branches à valider, avec, pour chacune, différents tests à valider, il est vite devenu difficile de suivre quels étaient les jobs lancés pour chaque branche et l’état de ces différents jobs au fur et à mesure du développement.

Les développeurs se trouvaient en manque d’outil pour faire ce suivi de validation. Chacun faisait alors avec sa propre méthode (papier, feuille de calcul, etc.).

enkins Khan v0

Une version plus synthétique correspondrait au tableau ci-dessous :

Matrice JK

Le maintien d’une telle feuille est vite devenu fastidieux, un correctif entraînant, la plupart de temps, la relance d’un nouveau build Jenkins. De plus, Jenkins ne nous facilite pas la tâche pour suivre l’état d’un même job s’il est lancé sur plusieurs branches : aucune vue n’affiche la liste des builds avec ses paramètres utilisés. Il faut donc aller sur la page d’affichage des paramètres transmis de chacun des builds pour visualiser la branche concernée par le build.

C’est pourquoi nous avons développé Jenkins Khan. L’objectif principal de cet outil est de visualiser l’état global de chacune des branches testées et l’état de ses différents jobs. Contrairement à Jenkins qui offre une vue orientée par job, Jenkins Khan a une vue orientée branche.

Jenkins Khan

La partie de gauche permet de visualiser les différentes branches en cours de validation, la couleur indiquant l’état (succès, échec, en cours de traitement, en attente, etc.). La partie de droite liste pour chaque job de cette branche :

  • son état,
  • sa progression,
  • sa date de lancement,
  • sa durée,
  • un lien pour le relancer,
  • des liens d’accès aux pages Jenkins (résultats, console, etc.).

Désormais, lors de la validation technique d’une branche, nous saisissons le nom de la branche de travail, choisissons la liste des jobs à lancer, et voilà : il ne reste plus qu’à attendre que tous les jobs soient terminés.

Testing d'une branche de travail

Basé sur l’API de Jenkins, Jenkins Khan nécessite peu de configuration :

  • l’url du Jenkins,
  • un paramètre BRANCH dans les jobs.

Le reste de la configuration (vues, paramètres des jobs) est fourni par Jenkins.

Nous avons également ajouté la possibilité de planifier des jobs pour qu’ils puissent être lancés à une heure donnée. On peut ainsi lancer les jobs coûteux en ressource machine hors horaire de travail.

Jenkins Khan possède une API permettant de créer et lancer des jobs pour une branche donnée. Nous l’avons ainsi intégré dans notre dashboard qui monitore les tickets sur lesquels nous sommes en train de travailler pour indiquer l’état de la validation.

Qa-monitor : monitoring des tâches en cours

Si vous voulez en savoir plus sur cet outil, vous pouvez consulter le dépôt Github qui héberge les sources https://github.com/pmsipilot/Jenkins-Khan. Le wiki du projet https://github.com/pmsipilot/Jenkins-Khan/wiki contient la documentation sur l’installation, l’API fournie, branchement sur un LDAP, etc. sur. Vous trouverez également sur le dépôt https://github.com/pmsipilot/jenkins-php-api les classes PHP nous permettant de manipuler les serveurs Jenkins grâce à leur API.

mar

4

Code review

By Serv-Tech

Code review appears to be one of the most important factors of code quality improvement (more so than unit testing ?). We therefore developed Crew, an open-source software which allows us to review Git projects.

More or less insprired by Github, Crew allows us to see all differences and to comment on Git project branches, files or even lines.

Crew

Read more »

fév

28

De l’utilisation du couple Behat/Sahi sur différents browsers

By Serv-Tech

Différents brothers

Jusqu’à peu, nous utilisions Behat pour sa définition principale : confirmer la stabilité des fonctionnalités de nos applications et leur non régression dans le temps. Une partie de ces fonctionnalités faisant appel à du javascript, nous l’avons tout naturellement couplé à Sahi (la dernière version en date étant la 3.5) et Chrome. Nous avons récemment décidé d’étendre ces tests à d’autres navigateurs afin de nous assurer une compatibilité cross-browsers de notre application.

Et là, c’est le drame : un tsunami d’erreurs. Comme le disait récemment un tavernier près du port de Cherbourg : « ce qui plaît à un navigateur ne plaît pas forcément à un autre ». Nous nous sommes donc plongés dedans et voici donc la liste non exhaustive des écueils auxquels nous avons été confrontés. Et vu qu’à PMSIpilot on n’est pas des requins, on vous met aussi les solutions apportées. [/fin de la minute maritime]

Read more »

fév

8

La qualité

By Serv-Tech

La qualité

Un projet est composé de quatre variables :

  • le périmètre fonctionnel (quoi),
  • la qualité (comment),
  • les ressources (qui),
  • le temps (quand).

J’ai volontairement classé ces variables dans l’ordre où il me semble qu’elles devraient être définies. Mais nous ne vivons pas dans le monde des Bisounours et c’est pourquoi la qualité est en général la variable qui sert à laisser de la marge aux autres.

Read more »

fév

6

Améliorez votre confort avec Behat

By Serv-Tech

Aujourd’hui je vais vous montrer quelques astuces qui vont peut être sauver votre santé mentale quand vous vous apprêtez à lancer une longue suite de tests avec Behat pour valider votre développement. En vrac on va parler de filtres pour lancer des scénarios spécifiques, de pouvoir lancer vos tests en arrière plan, d’utiliser le système de hooks pour faire des notifications, et même des captures d’écran !

Read more »

jan

20

Barcamp sur les méthodes agiles à Lyon le 3 mars 2012

By Serv-Tech

Nous utilisons des méthodes agiles inspirées de SCRUM au sein de nos équipes de travail, et nous aimons améliorer nos connaissances et apprendre. Du coup, nous proposons un Barcamp d’une journée. Nous espérons voir arriver des personnes de l’agglomération lyonnaise et alentours.

Un Bar Camp est une « non-conférence » ouverte qui prend la forme d’ateliers-événements participatifs où le contenu est fourni par les participants qui doivent tous, à un titre ou à un autre, apporter quelque chose au Barcamp, l’objectif est avant tout de partager des idées.

Tous les participants sont invités à parler du Barcamp autant avant leur participation, qu’après, pour rendre compte de leurs échanges.

  1ère règle: Tu parleras du BarCamp.

2ème règle: Tu blogueras à propos du BarCamp.

3ème règle: Si tu veux faire une présentation, tu dois inscrire ton sujet et ton nom dans un slot de présentation.

4ème règle: Des intros de 3 mots seulement.

5ème règle: Autant de présentations à la fois que l’infrastructure le permet.

6ème règle: Pas de présentations réservées à l’avance, pas de touristes.

7ème règle: Les présentations iront tant et aussi longtemps qu’elles le doivent, où jusqu’à ce qu’elles se heurtent à l’heure de début de la présentation suivante.

8ème règle: Si c’est votre première fois au BarCamp, vous DEVEZ présenter. (Bon, on ne va pas vous forcer, mais essayez de trouver quelqu’un avec qui présenter, ou posez des questions et soyez un participant actif.)

par Tantek Çelik, en parodie des Règles de Fight Club.

L’accès se fait via une inscription préalable et est limité à 40 participants, pour des raisons légales. Au delà de 40, vous serez en liste d’attente.

Nous vous attendons samedi 3 mars de 10h à 18h dans les locaux de PMSIpilot, 61 r Sully, Lyon 6ème.

Plus de détails sur la page Barcamp de l’événement.

 

jan

13

Éviter les fuites mémoire avec Propel

By Serv-Tech

Fatal error: Allowed memory size of 67108864 bytes exhausted (tried to allocate 32 bytes)

Si vous n’avez jamais rencontré le message ci-dessus alors que vous faites un traitement par lot avec Propel 1.6 (gros import de donnée, démon PHP qui manipule la base et tourne en permanence), alors vous pouvez passer votre chemin !

Read more »