Behind the curtain

b1...b7, rc1....rcN, X.0

Depuis quelques temps maintenant nous sortons des versions de Blue Mind. On leur donne des noms "marketing" genre beta1, beta7, rc1... mais qu'est ce qui ce cache derrière tout ça ?

Scrum & versions

L'équipe utilise une méthode scrum avec des sprints. Ces sprints peuvent se retrouver dans nos numéros de version :

• 0.22.1234 correspond à l'itération 0, branche de développement de la version 1. Au 22ième sprint, et au build 1234 de notre intégration continue.
• 1.0.1566 est une version stable. Notre première normalement. Le numéro de sprint restera toujours à 0, les bugfix entrant dans cette branche étant indépendant de planning agile. 1566 est toujours notre numéro de build jenkins.
• 1.1.1755, une version intermédiare, on the road to "2.0.x".

Numéros de build

Les numéros de builds sont importants pour Blue Mind. Il permettent d'identifier de manière unique une version. Ils sont utilisés par le Setup Wizard dans la version pro pour exécuter les mises à jours : je vais de 0.22.1234 à 1.0.1666. Je dois exécuter tous les programmes de mise à jour entre ces versions.

Comme pour beaucoup de projets, ces numéros sont généralement soit :

• un numéro de révision svn
• un numéro de build jenkins

Le notre est "presque" un numéro jenkins. Mais voilà, Blue Mind a de nombreux composants et son intégration continue est compliquée....

Un build complexe

D'après ohloh, Blue Mind c'est 64% de java et 18% de javascript (le reste étant de la plomberie XML/sh autour de ça). 

Ceci n'est pas complètement vrai. Ohloh n'indexe que la version community. La version pro ajoute son lot de fonctionnalités, et de languages :

Totals grouped by language (dominant language first):

java:        206174 (93.63%)

cs:           11981 (5.44%)

sh:            1789 (0.81%)

jsp:            149 (0.07%)

cpp:            106 (0.05%)

Ci dessus le resultat de sloccount sur le repository "closed" de Blue Mind. Les 11000 lignes de c-sharp du connecteur outlook sont une partie de problème.

Pour compiler ce genre de choses il faut :

• des slaves jenkins sous windows
• visual studio, VSTO, etc

Et même la version community n'est pas si simple :

• compilation de cyrus sur :
• lucid
• precise
• rhel6
• compilation du connecteur thunderbird sur une lucid 32bits
• déploiement des artifacts de compilation (deb, rpm, xpi, etc) et execution des tests unitaires sur ces plateformes

Et pour publier tout ça :

• des dépots public pour distribuer les beta/rc/versions
• des dépots pour nos clients avec les briques propriétaire

Ce qui represente pas mal de machines virtuelles VMWare avec diverses fonctions.

On the road to 1.0

Jusqu'à maintenant nous n'avions que la version "de dev" qui va devenir la 1.0. Et c'était déjà pas mal :

• 16 projets jenkins
• 2 gits, 3 avec celui pour nos dépendances de compilation. Plus les git de cyrus...
• des machines virtuelles de tests : rhel6 (rw), lucid (rw), ldap (ro), active directory (ro), hosts (rw, la machine qui nous sert à tester l'ajout de nouveau serveurs sur une infra)

Disons que chacun de nos projets jenkins a son intêret. Sortir une version maintenue implique avoir le même niveau de qualité sur cette version. Donc à minima :

• 2 branches git à créer
• 16 projets jenkins à cloner
• 3 machines virtuelles à dupliquer

Pour faire ce genre de trucs, normalement, il vaut mieux mettre la majorité de l'équipe en RTT et 1/2 personnes font le travail.

Chez Blue Mind un des principes fondateurs est de tout indistrualiser, que ce soit pour le commerce avec scenari et e-deal ou pour la R&D.

On a donc essayé de dé-dramatiser cette 1.0 à venir, et on a anticipé sur une fréquence de release rapide (le commerce dirigeant la technique, s'ils veulent une version, on doit pouvoir la fournir).

L'objectif était :

"en tant que MembreDeLequipe je peux créer une nouvelle version à volonté et bénéficier des mêmes contrôles qualité que sur la version en cours de dev"

Backoffice is born

Ce qui est cool avec tous les outils que nous avons en place :

• git
• jenkins
• redmine
• vsphere

C'est qu'ils ont tous des API java utilisables. Automatiser notre process de release est donc surement faisable. On a besoin de :

• brancher nos git
• cloner nos projets jenkins et les re-pointer sur la nouvelle branche
• cloner nos machines virtuelles de test
• faire des commits dans la nouvelle branche pour cibler les tests vers les nouvelles VMs
• mettre en ligne la version

On ne voulait pas non plus que pour faire l'opération de release 4 personnes soient nécessaires : attend c'est Sylvain qui sait comment on upload la release et fait la branche. Faut que Thomas copie et modifie nos projets jenkins, etc.

Comme quand on a un marteau, tout ressemble à un clou, on a refait toute une application de "backoffice" avec le même niveau d'industrialisation que Blue Mind.

bm-backoffice

Un web service assez proche de Blue Mind Core dans sa structure, mais avec des API différentes. Il nous sert aussi de test-bed pour des évolutions futures de Blue Mind core. Par exemple au lieu de faire du XML/RPC il utilise une API web service à base de JSON qui utilise Jackson, assez proche de celle de http://get.gaug.es/documentation/api/ 

bm-backoffice-wizard

Une wizard d'installation / upgrade pour maintenir la base de données du backoffice.

bm-console

Une console d'admin dédiée à la gestion de nos builds/sprints/releases et leur mise en ligne.

De bons outils pour un bon niveau d'industrialisation.

Cet outil sait brancher nos gits, va automatiquement cloner et mettre à jour les projets dans jenkins, et sait mettre une release Blue Mind en ligne. Le travail sur nos VMs au travers des API vsphere est en cours.


What else ?