Leave a comment

Lancement de la communauté Software Craftsmanship sur Nantes

Mardi soir a eu lieu la soirée de lancement de la communauté Software Craftsmanship sur Nantes. Encore merci à l’Epitech pour l’accueil et à Zenika pour les pizzas/bières !

Cela faisait un bout de temps que Maxime, Sébastien et moi-même parlions de lancer ce meetup. C’est donc fait, et malgré un nombre de personnes présentes réduit, la soirée s’est super bien déroulée !

En attendant l’arrivée de tous les participants, Sébastien a proposé un petit IceBreaker pour montrer les problèmes d’un code “spaghetti” quand on veut faire du refactoring. Il a pour ce faire détourné l’atelier “Le noeud humain”, et je dois dire que ça fonctionne plutôt bien !

image20160419_191046015

Ensuite, Rui nous a parlé de sa vision du Software Craftsmanship. Sa présentation était simple, claire et décomplexante. Merci à lui d’être venu jusqu’à Nantes pour nous parler !

image20160419_192133985

Nous avons ensuite entamé la partie Open Space de la soirée. Il y avait beaucoup de sujets proposés, tous très intéressants. Les choix ont été difficiles ! Nous en avons choisi 2 : BDD et “Comment s’assurer de la qualité du code lorsqu’on a un turn-over important dans les équipes”

image20160419_201057361

Pour ma part, j’ai participé au groupe traitant du turn-over. Pour résumer rapidement les discussions, nous avons parlé Pair-programming, revue de code, organisation de dojos en entreprise, … En espérant que nos discussions auront aidé la personne ayant posé le problème🙂

Suite à ces discussions, nous sommes passés à la phase pizzas/bières. Là encore, beaucoup de discussions plus informelles.

Un grand merci à tous les participants. J’espère que cette soirée vous aura plu !

Leave a comment

Migration SVN -> Git – Part 2

Suite de mes pérégrinations avec la migration git vers svn (1ère partie ici).

Elle n’a pas été de tout repos et a pris un peu de temps (d’où le délai entre la 1ère et la 2ème partie de ce post…)

Le workflow utilisé

Nous avons décidé de partir sur le workflow gitflow, en utilisant la branche “support”. En effet, le produit est déployé sur les serveurs des clients et les mises à jour se font à un rythme assez lent. Nous nous retrouvons donc à devoir réaliser la maintenance de nombreuses anciennes versions tout en développant les nouvelles fonctionnalités. Cette branche “support” permet donc de créer des patchs sur les anciennes versions, sans forcément les reporter sur les autres branches (le report doit se faire manuellement car la base de code peut avoir énormément changé entre temps).

Revue de code ?

Nous réalisons systématiquement des revues de code avant chaque commit, sans pour autant utiliser d’outil pour cela (on privilégie la communication en face à face😉 ). La question s’est posée d’intégrer un outil comme gerrit pour s’assurer que cette revue de code était bien réalisée.

Finalement, pour simplifier la prise en main de git dans un premier temps, nous avons décidé de ne pas  le mettre en place et de conserver notre fonctionnement actuel. On verra à l’usage si un outil est vraiment nécessaire !

Définition des projets “pilotes”

Après avoir fait le ménage dans la liste des projets pour ne conserver que les ceux qui étaient encore utilisés, nous avons définie une liste de projets qui serviraient de pilotes à cette migration (pour éviter l’effet big-bang et s’assurer que tout fonctionne bien).

Nous n’avons évidemment pas choisi le cœur de l’application, mais un outil qui permet de gérer les migrations et qui faisait des requêtes sur le serveur SVN. Étant donné qu’il fallait le modifier pour remplacer tous ces appels par des appels vers Git, le pilote était tout trouvé !

Pour réaliser ces appels vers le serveur Git, nous avons utilisé la librairie JGit.

Voici quelques exemples d’appels:

SVNCheckout    => git.checkout().setName(« Nom de la branche »).call() ;
Checkout partiel: git.checkout().addPath("file1.txt").addPath("file2.txt").call();
SVNCommit      => git.commit().setMessage(« blabla »).setCommitter(nom, email).call() ;
                  git.pull().call();
SVNAdd          => git.add().call();
SVNList        => utiliser RevWalk pour parcourir les fichiers
SVNLog         => Récupérer les 10 derniers commits de la branche courante:
               git.log().add(head).setMaxCount(10).call();
               => Entre 2 commits :
               git.log().addRange(since, until).call();
SVNStatus      => git.status().call() ;
SVNUpdate      => git.pull().setRemote(URL).call();

La migration !

Pour simplifier cette migration (qui doit migrer une dizaine de projets), j’ai donc réalisé un petit script bash :


#!/bin/bash
# Migration SVN -> GIT
# Author : Cécilia Bossard (cecilia.bossard@timwi.com)

function migration(){
    # Parametre 1 : nom projet
    # Parametre 2 : URL svn
    # Parametre 3 : derniere revision SVN a prendre en compte (facultatif)
    
    echo 'Migration '$1
    git svn clone $3 $2 --authors-file=users.txt --no-metadata -s $1
    
    cd $1/.git
    
    echo 'Creation tags'
    git for-each-ref refs/remotes/tags | cut -d / -f 4- | grep -v @ | while read tagname; do git tag "$tagname" "tags/$tagname"; git branch -r -d "tags/$tagname"; done
    
    echo 'Creation branches'
    git for-each-ref refs/remotes | cut -d / -f 3- | grep -v @ | while read branchname; do git branch "$branchname" "refs/remotes/$branchname"; git branch -r -d "$branchname"; done

    echo 'Nettoyage'
    git config --remove-section svn-remote.svn
    git config --remove-section svn
    rm -r svn
    git branch -D trunk
    
    cd ../..

    # Création d'un dossier "nu" partagé sur le serveur
    git clone --bare $1 $1.git
    rm -rf $1
    cd $1.git
    git config core.shareRepository true
    
    cd ..
    echo 'Fin migration '$1
}
migration nomProjet svn://svnabcd/nomProjetWeb/ -r33900
migration nomProjet2 svn://svnabcd/nomProjet2/
migration nomProjet3 svn://svnabcd/nomProjet3/

Plus qu’à exécuter le script sur le futur serveur et hop ! de beaux repos tout prêt🙂

Je me suis en suite attelée à la formation des développeurs (de la théorie, et surtout des démos de l’utilisation des nouveaux outils).

Passage du serveur SVN en lecture seule

L’ultime étape de cette migration a consisté à passer le serveur SVN en lecture seule (pour éviter les commits accidentels sur ce serveur)

1ère chose : sauvegarde du serveur

> svnadmin dump <dépôt-svn> | gzip -9 > <fichier-de-sauvegarde>

Puis passage en lecture seule :

Modification du fichier conf/svnserve.conf du dépôt

anon-access = none
auth-access = read

Et voilà🙂 Y’a plus qu’à ^^

Leave a comment

1er coding dojo en entreprise

Nous avons organisé notre premier coding dojo au sein de mon équipe.

Je tiens à remercier une fois de plus Xavier Nopre pour son aide et son inspiration !

J’ai commencé ce premier dojo en expliquant les principes du TDD (eh oui, le but était de se lancer dans cette pratique qui fait tellement peur). J’ai ensuite continué sur un premier exercice en mode “randori”. L’exercice était simple (a priori) : proposer un service de calcul de points au tennis.

Bilan : l’équipe a produit du code pas franchement très propre… Mais après une petite rétrospective, ils m’ont avoué qu’ils l’avaient fait exprès, parce qu’ils ne prenaient pas l’exercice au sérieux. Ce n’était pas du code de production, alors ils se sont permis de faire un peu n’importe quoi. Ouf !

Bilan (bis) : on recommence en janvier ! But du prochain exercice : l’utilisation de mocks. A suivre donc🙂

Leave a comment

Lancement des coding goûters sur Nantes

codingGoutersNous sommes très heureux d’annoncer le lancement des coding goûters sur Nantes !

Suite au succès des Devoxx4Kids nantais, nous avons décidé de lancer un évènement plus récurrent (les WIT, le GDG et le JUG) . Encore merci à la Cantine de nous accueillir !

Toutes les infos sont disponibles ici : http://nantescodinggouters.wordpress.com

Leave a comment

Human Talks à Nantes

Le 16 septembre, j’ai eu le plaisir de faire une présentation aux Human Talks à Nantes. Le sujet ? L’agilité bien sûr😉

Les slides de ma présentation sont dispos ici : L’agilité en 10 minutes

N’hésitez pas à me faire un retour sur cette présentation !

1 Comment

Migration SVN -> Git – Part 1

Suite à un atelier sur la gestion de la dette technique sur le projet sur lequel j’interviens actuellement, nous avons décidé d’étudier si Git pouvait nous aider à nous sortir des méandres de nos branches SVN. Voici le récit de cette migration.

Première étape : tests sur mon poste

Pour commencer à tester, j’ai installé une VM de test pour y installer un repo Git et l’utiliser comme serveur. Jusqu’ici, c’est simple ^^

J’ai ensuite procédé à la migration SVN vers Git sur ce serveur de test :

Deuxième étape : la migration SVN vers Git

Pour cela, j’ai utilisé les scripts suivants

  • Migration

> git svn clone svn://serveurSvn/projet/projetWeb/ --authors-file=users.txt --no-metadata --shared -s projetWeb

Un peu laborieux. Je  n’avais pas l’historique de tous les commiteurs SVN. A chaque commiteur inconnu, le script s’arrête et il faut mettre à jour le fichier users.txt et relancer le script.

Petite astuce : quand le script plante et doit être relancé, enlever les lignes branches et tags du fichier .git/config

Après avoir laissé tourné le script pendant une journée complète, nous avons décidé de ne récupérer que les branches les plus récentes (le projet a 10 ans d’existence, et honnêtement, on ne va jamais regarder l’historique d’il y a 3 ans…). Nous avons donc conservé les versions pour lesquelles il y avait encore des clients les utilisant.

La récupération se fait donc branche par branche, en commençant par le trunk

> git svn init --prefix=trunk svn://serveurSvn/projet/projetWeb/trunk
> git svn --authors-file=users.txt fetch

Même procédure pour chaque branche à récupérer

> git config --add svn-remote.brancheArecuperer.url svn://serveurSvn/projet/projetWeb/branches/brancheArecuperer
> git config --add svn-remote.brancheArecuperer.fetch :refs/remotes/brancheArecuperer
> git svn fetch brancheArecuperer
  • Déplacement des étiquettes

> git for-each-ref refs/remotes/tags | cut -d / -f 4- | grep -v @ | while read tagname; do
 git tag "$tagname" "tags/$tagname"; git branch -r -d "tags/$tagname";
 done
  • Création des branches

> git for-each-ref refs/remotes | cut -d / -f 3- | grep -v @ | while read branchname; do
 git branch "$branchname" "refs/remotes/$branchname"; git branch -r -d "$branchname";
 done
  • Suppression de la branche trunk (inutile => utilisation du master)

> git branch -D trunk

Troisième étape : Utilisation de SourceTree sur les postes des développeurs

Dans un premier temps, pour faciliter l’adoption de Git, j’ai cherché un outil permettant de visualiser facilement l’état des branches et comment tout cela pouvait fonctionner.

J’ai opté pour SourceTree, principalement pour sa simplicité d’utilisation et son intégration de gitFlow

Quatrième étape : Définition du workflow : gitFlow

Ce workflow me paraît très adapté à la façon dont le projet vit (ou plutôt devrait vivre) :

http://nvie.com/posts/a-successful-git-branching-model/

Cinquième étape : Tests de git-svn

Étant donné que je ne sais pas encore comment va être adopté Git, j’ai voulu tester git-svn, pour voir si ce mécanisme pouvait aider mes collègues à se familiariser avec les commandes Git sans pour autant faire le grand saut directement.

J’ai suivi le tutoriel suivant pour réaliser cette opération : https://git.wiki.kernel.org/index.php/Git-svn

J’ai donc commencé par récupérer les sources du projet sur mon poste via la commande suivante :

> git svn clone -r HEAD https://mysvnsrv.org/rep/trunk repertoireTest

A partir de là, j’ai présenté le résultat à mes collègues. Gros problème, le projet est tellement volumineux qu’on ne peut pas avoir toutes les sources sur le poste des développeurs. Avec SVN, on réalisait un checkout partiel. Cette commande n’est pas présente telle qu’elle sous Git.

Après quelques recherches, il s’avère qu’un sparse checkout peut résoudre le problème. Ouf ! Mais cette limitation a également mis en avant le problème principal du projet : son volume. Une action parallèle a également consisté à lui faire faire un régime en supprimant des écrans inutilisés et en passant de struts 1 à struts 2 (oui c’est un vieux projet). 40 000 classes en moins, et on peut désormais récupérer toutes les sources sans qu’Eclipse ne soit à l’agonie !

A suivre :

Sixième étape : Formation des développeurs

Septième étape : Migration sur un vrai serveur

Huitième étape : On coupe SVN ? (ou comment gérer la maintenance des anciennes versions ?)

Leave a comment

BreizhCamp (3/3)

Jour 3

En ce dernier jour de conf, j’y suis allée sans stress et bien reposée.

Keynote

Le thème de la keynote était, en gros, travailler dans une start-up, c’est cool. Bon… mis à part une overdose de gifs animés qui n’étayaient en rien le propos des orateurs, il n’y avait pas grand chose… Je ne vais donc pas m’attarder sur ce sujet (une remarque tout de même : les gars, OK, c’est une confs de devs, mais il y a aussi quelques filles, alors faites un peu attention à vos slides)

Trend it

Un retour d’expérience sur l’utilisation de l’outil Graphite pour réaliser des graphiques représentant ce qu’il se passe sur les serveurs. L’outil semble intéressant, mais j’avoue avoir été un peu perdue au cours de la présentation. Je pense que je devrais mettre les mains dedans pour mieux l’appréhender.

Des petits pas vers le Continuous Delivery

Très bonne présentation du passage en déploiement continu chez Les Furets. Je garde en tête le passage d’une mise en prod tous les 6 mois à une mise en prod par jour (ça donne des perspectives d’amélioration pour certains projets ^^). Les outils qu’ils ont utilisés sont éprouvés et reconnus (git, selenium, … ) mais ils ont su les utiliser intelligemment pour atteindre leur but. Bravo !

Le passage de SVN avec trunk + branche maintenant à git avec master et pull request fait étrangement écho à la situation dans laquelle est le projet sur lequel je travaille actuellement (je milite depuis 6 mois pour qu’on passe à git)… Je ne connaissais pas le merge octopus et je vais m’y intéresser plus en détail rapidement !

UX Design, Design thinking…? De quoi parle t-on ?

Une explication claire et rafraichissante de tout ce qu’on entend par UX Design. Je ne vais pas détailler ici toute la session (la vidéo sera disponible prochainement). Les parallèles avec les outils que l’on peut utiliser dans l’agilité pour récupérer les besoins des utilisateurs sont similaires (personas…), et c’est logique. Cette phase de conception préliminaire manque (trop) souvent aux projets et feraient un bien fou (surtout pour éliminer les fonctionnalités inutiles).

Vers des infrastructures agiles

J’ai continué dans le thème DevOps pour écouter ce que Sylvain Revereault avait à dire sur le sujet : beaucoup de choses intéressantes ! Là encore, je ne vais pas détailler tout ce qu’il a pu dire et je vais vous laisser découvrir la vidéo.

Ionic In Action

J’ai terminé la journée en assistant à un tools in action sur Ionic. Je ne connaissais pas du tout (il faut dire que je ne fait quasiment pas de développement sur mobile). Le framework semble simple et facile d’utilisation. Un petit lien pour en apprendre plus : http://learn.ionicframework.com/

 

Et voilà, terminé pour moi. Je suis donc rentrée sur Nantes avec plein de nouvelles idées à mettre en œuvre (et plein de vidéos à regarder des sessions auxquelles je n’ai pas pu assister).

Encore merci et bravo aux organisateurs. Vivement l’année prochaine !