De l’organisation et de la planification avec pmsiplan

Dans le monde de la gestion des logiciels, il existe un endroit redouté appelé « l’enfer des dépendances » (de l’anglais « dependency hell »). Plus votre système se développe et plus vous intégrez de composants dans votre logiciel, plus vous êtes susceptible de vous trouver un jour dans cette abîme de désespoir.

Semver.org

Les questions sous-jacentes sont souvent les suivantes :

  • Quel numéro de version retenir pour une brique logicielle dépendant elle-même de sous briques également versionnées ?
  • Comment gérer les montées de versions et breaking changes ?
  • Quand planifier une nouvelle version si les projets dont je dépends ne sont pas prêts ?

Pour pallier ces problématiques de release management, nous avons mis en place certaines bonnes pratiques :

  • Gestion de dépendances en utilisant RPM/Yum,
  • Semantic Versionning, pour pouvoir détecter rapidement les breaking changes,
  • un CHANGELOG.md dans chaque projet,
  • un UPGRADE.md si nécessaire.

En plus de ces pratiques, nous avons développé un outil sympa de gestion de release permettant :

  • au Release Manager d’avoir une vision rapide des dates de livraisons prévues pour chaque brique logicielle, et quelle version de chaque brique logicielle sera incluse dans une release ou quelle brique retarde la sortie de la release avec un petit diagramme de gant rapide pour la sortie de la release …
  • au Lead Dev de chaque brique de savoir quelles dépendances vont être mise à jour, de planifier la montée en version de ces dépendances et planifier la mise à jour de l’application dont il est le responsable.

Et comme nous sommes sympas chez PMSIpilot et qu’on aime bien l’open source, notre projet PMSIplan est désormais open sourcé sur github !
PMSIplan

 

Ordonnez vos git rebase grâce à l’autosquash

Chez PMSIpilot, nous utilisons git depuis déjà plusieurs années.
Ce merveilleux outil recèle de nombreuses commandes et options parmi lesquelles, une, dont je vais vous parler aujourd’hui :

git rebase -i --autosquash "branchname"

Très rapidement, car les ressources ne manquent pas à ce sujet, la commande git rebase va « déplacer » la base de votre branche courante en l’accolant au dernier commit de la branche passée en argument.
Pour reprendre la documentation officielle voici ce que ça donne

      A---B---C topic
     /
D---E---F---G master
git rebase master
              A'---B'---C' topic
             /
D---E---F---G master

L’options interactive git rebase -i ajoute la possibilité de retravailler l’arbre de votre branche, en modifiant le message, le contenu ou même l’ordre de vos commits (ici A, B et C).
Il vous suffit pour cela d’associer une action à chacun de vos commits via l’éditeur qui s’ouvre lorsque vous tapez la commande.

....
# Commands:
# p, pick = use commit
# r, reword = use commit, but edit the commit message
# e, edit = use commit, but stop for amending
# s, squash = use commit, but meld into previous commit
# f, fixup = like 'squash', but discard this commit's log message
# x, exec = run command (the rest of the line) using shell

On notera notamment 2 actions qui vont nous intéresser par la suite, fixup et squash.
Ces commandes permettent de fusionner un commit avec le précédent (au contraire de fixup, squash gardera le message du commit fusionné).
L’autre attrait de l’option interactive est aussi de pouvoir modifier l’ordonnancement de vos commits.

Imaginons que vous souhaitiez merger A et C, il vous faudra déplacer le commit C puis lui assigner la commande squash.

C’est bien beau mais l’autosquash dans tous ça ?

Justement, que diriez vous si git pouvait vous pré-macher le travail en accolant directement les commits que vous souhaitez merger et en leur assignant directement la bonne action ?
C’est justement le but de l’autosquash.

Cas concret

Pour être plus clair rien ne vaut un bel exemple bien illustré.

Je viens de créer une branche partant de master pour ajouter un readme dans mon projet, appelons la add_readme.

Après avoir saisi une introduction je décide de faire un 1er commit :

$ vim README.md
...
...
$ git add README.md && git commit -m'Project introduction'

Je m’attaque ensuite aux pré-requis, que j’ajoute dans un second commit :

$ vim README.md
...
...
$ git add README.md && git commit -m'Project prerequisites'

Et là, catastrophe, j’ai oublié de saisir une partie de mon introduction.

J’ajoute donc les infos à mon fichier mais cette fois-ci lors du commit je vais ajouter un message particulier :

$ vim README.md
...
...
$ git add README.md && git commit -m'fixup! Project introduction'

Vous constatez que j’ai repris le message de mon 1er commit (notamment la 1ère ligne) préfixé de l’expression fixup!.

Pour l’instant cela ne change rien a mon arbre, un simple git log vous permettra de le constater.

$ git log --abbrev-commit --pretty=oneline
34a3c01 fixup! Project introduction
94168ce Project prerequisites
9b9d032 Project introduction
62b7328 initial commit

Mais lorsque je lance ma commande git rebase -i --autosquash master git me positionne automatiquement mon dernier commit en seconde position associé à la commande fixup

pick 9b9d032 Project introduction
fixup 34a3c01 fixup! Project introduction
pick 94168ce Project prerequisites

# Rebase 62b7328..34a3c01 onto 62b7328
#
# Commands:
# p, pick = use commit
# r, reword = use commit, but edit the commit message
# e, edit = use commit, but stop for amending
# s, squash = use commit, but meld into previous commit
# f, fixup = like 'squash', but discard this commit's log message
# x, exec = run command (the rest of the line) using shell
....

Il me suffit de valider cet arbre en sortant de mon éditeur préféré et git se charge du reste.

Bonus

Durant la rédaction de cet article j’ai découvert que l’on pouvait même laisser git générer lui-même le message de « squash » en lui indiquant le hash du commit de fusion.

Pour reprendre notre exemple, cela aurait donné :

$ git commit --fixup 9b9d032
[add_readme 5d291ee] fixup! Project introduction
1 file changed, 2 insertions(+), 1 deletion(-)

Au dela de l’outil

La commande que je viens de vous présenter peut vous paraître superflue mais pour moi elle est un argument principal pour défendre une des « best practice » git : « commit early, commit often »

En effet, pour travailler quotidiennement sur une application assez importante et avec un historique de plusieurs années je suis parfois confronté à des blames du type : « Ajout de la feature machin » avec un commit de 36 fichiers modifiés alors que j’aimerais simplement comprendre le raisonnement du développeur lorsqu’il a ajouté ce petit bout de code qui me pose question.

La difficulté des « Early Commit » c’est que lors du développement d’une feature globale on revient régulièrement sur des parties déjà commitées pour les modifier sans pour autant changer la fonctionnalité associée au commit.

Grâce à l’autosquash je peux effectuer mes modifications en empilant mes commits les uns a la suite des autres.
Lorsque ma feature est prête et que je souhaite la publier, je lance mon rebase qui va réécrire automatiquement mon historique.

 

PMSIpilot UI, le thème bootstrap made in PMSIpilot

Chez PMSIpilot, nous développons une multitude d’applications web, que ce soit pour nos clients, ou pour des outils internes. Et pour chaque application, nous sommes confrontés à la problématique du design, de la cohérence par rapport aux autres applications. L’idée d’avoir une base commune s’est donc rapidement imposée.

riad-query

Préconisations

  • Lorsqu’on parle de librairie graphique CSS, on pense souvent à Twitter Bootstrap. Donc pour simplifier l’intégration de nos applications (majoritairement Angular.js) avec les différentes librairies Javascript qui génèrent du code Bootstrap ready, nous avons décidé de développer notre librairie sous forme de thème Bootstrap.
  • Aussi, nos applications doivent avoir la même base, mais une identité unique à chacune des applications à travers les couleurs. Nous avons donc mis en place un système de thème assez simple pour permettre à chaque application de choisir trois couleurs principales.
  • Avec un versionning en semver, et une compilation less effectuée au plus tard (côté application), le workflow de mise à jour du design de nos différentes applications s’est retrouvé grandement amélioré.

Téléchargement
La librairie UI est disponible sur Github et une démo est disponible ici.

Utilisation

Installer la librairie

bower install pmsipilot-ui --save

Inclure les less, et personnaliser son thème

@import 'bower_components/fontawesome/less/font-awesome';
@import 'bower_components/bootstrap/less/bootstrap';
@import 'bower_components/pmsipilot-ui/less/bootstrap';

body {
    .theme-colored(@themeColorOne, @themeColorTwo, @themeColorThree);
}
 

Agile Barcamp Lyon : Kanban

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
 

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

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]

… 

 

La qualité

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.

… 

 

Améliorez votre confort avec Behat

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 !

… 

 

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

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.

 

 

Ressources sur les API REST

Les API REST c’est bien. Mangez-en !

 

Squashons avec GIT

Dans ce premier article consacré aux astuces GIT, je vais vous parler d’une technique permettant de regrouper un ensemble de commits en un seul.

…