Mon premier Paris JUG

Hier soir je suis allée pour la première fois à la réunion mensuelle de Paris JUG. Je suis allée avec le groupe JDuchess. Ceci a été une expérience géniale. Jusqu'à hier, je connaissais les duchesses par la toile, et enfin j'ai pu les rencontrer et leur donner un visage (au moins à la dizaine de participantes)

Voici mes retours de la soirée

DVCS par Sebastien Douche
Git par David Gageot

Conférences très bien animées, avec beaucoup d'humour et très intéressantes. DCVS, Distributed Control Version System, est la version distribuée des systèmes comme CVS et SVN.
Sebastien et David, avec leurs nombreuses années d'expérience, ont constaté que :

- Chaque développeur a "sa façon de faire" : petits commits fréquents, gros commit à la fin, commiter toujours à la fin de la journée etc.
- Face à un développement assez important :

• Le développeur passe beaucoup de temps à "merger" les changements pour pourvoir après commiter
• Beaucoup de micro-merges sont effectués pendant la journée car la quantité de fichiers à merger est proportionnelle au temps passé sans commiter.
  
• Le développeur se dépêche de commiter principalement pour laisser la fastidieuse tâche de merger à son voisin.
• Commits fréquents, non testés, non finis, non validés

Toutes ces problématiques, encore plus aggravées dans un projet qui commence "from scratch", sont la cause directe de :

• Trop de temps perdu
  
• Un projet moins stable
• L'impossibilité de montrer le produit au client au fil de l'eau
  
• Un impact négatif sur la gestion du projet

Si on utilise des branches pour paralléliser les développements, les conséquences seront encore pires : personne n'aime les fusionner ; il est connu que cette tâche est un véritable cauchemar et que leur gestion amène beaucoup de problèmes.

La solution :
Oublier l'utilisation des gestionnaires de versions comme CVS ou SVN et utiliser DVCS, notamment Git.

Principes : le workflow et l'orientation au contenu.

Workflow: Un développeur est confronté à plusieurs workflows.

• workflow organisationnel : Il s'agit de la organisation qu'il faut mettre en place pour le développement d'un produit.

• workflow personnel : Il s'agit de la façon de travailler de chaque développeur

• workflow inter-personnel : Il s'agit de la façon dont chaque développeur travaille avec l'équipe autour de lui

Orientation au contenu :
Contrairement au CVS ou SVN (outils VCS) qui sont orientés au ChangeSet, les noms des fichiers sont dissociés aux contenus.

Chaque acteur compte avec son repository en local et peut s'organiser comme il veut. On fait tous les commits qu'on souhaite.
Une fois la fonctionnalité est finie, on "push" l'ensemble fonctionnel sur le repository central.

Ainsi :

- Nous nous focalisons sur notre code
- Nous avons tout l'historique en local
- La résolution de conflits est plus intelligent
- Nous pouvons travailler en mode déconnecté
- Il nous permet d'automatiser l'intégration continue en local et de pusher automatiquement au dépôt central si le build est stable.
- Il est capable de détecter les renommages des fichiers rendant faciles et rapides les refactoring du code.
- Non seulement toutes les utilités de SVN sont disponibles mais plus encore ; par exemple, "git bisect" nous aide à savoir quel commit a cassé notre build en l'absence d'erreur de la part du serveur d'intégration continue.
- Vitesse, souplesse et cherry picking entre autres caractéristiques.


Plus de .svn et .cvs partout ! Plus de regrets lors de la copie d'un répertoire !

Et pour commencer en douceur et convaincre le client ?
Binding ! On peut garder notre serveur SVN et travailler avec Git :o)

La meilleure façon de commencer est la pratique : GitHub !

J'ai déjà utilisé GitHub pour "Tapestwitter" http://github.com/lguerin/tapestwitter et je suis encore plus convaincue qu'hier matin !

Plus d'information sur le site : GIT - Fast Version Control System

ParisJUG : Paris JUG