Git : marche arrière chez No Parking
samedi 10 octobre 2015 :: perrick :: Développement :: 9 commentaires :: aucun trackbackAucun doute : Git a gagné la bataille des gestionnaires de code source. Même SimpleTest a migré vers GitHub et donc vers Git. Chez No Parking aussi, nous avons lancé la transition de Subversion vers Git avec les débuts de Lozeil.
Et puis nous avons fait marche arrière pour deux raisons.
Tout d'abord le problème des Submodules. Lozeil (comme Opentime d'ailleurs) est composé de 2 logiciels imbriqués : l'application d'une part et le back-office (qui gère le site web, toutes les instances des clients, les processus de facturation, etc.). L'un et l'autre s'articulent sans effort grâce aux svn:externals. La documentation sur les submodules de Git était prometteuse : il arrive souvent lorsque vous travaillez sur un projet que vous deviez utiliser un autre projet comme dépendance. Mais nous avons dû nous rendre à l'évidence : il s'agit là d'un point faible de Git - au moins dans notre cas. En effet nous souhaitons que les deux projets n'en fassent plus qu'un : nous mettons cette double "HEAD" en production régulièrement. La documentation de Git précise les choses : vous voulez être capable de gérer deux projets séparés tout en utilisant l'un dans l'autre. Nous n'étions pas fait pour nous entendre en fait !
Secundo les outils d'intégration continue, de déploiement automatique, de ticketing ont été construits pour Opentime et restent liés à Subversion. Passer à Git pour Lozeil impliquait de les ré-écrire, de les étendre ou de les remplacer. Nous avons préférés utiliser nos jetons d'innovation sur d'autres trucs à commencer par de l'algorithme de Fisher.
Subversion reste notre bonne vieille techno pour quelques temps encore.. Et cela n'empêche pas certains devs de profiter de la passerelle Git-SVN ;-)
Vos commentaires et/ou trackbacks
Le samedi 10 octobre 2015 à 17:38, commentaire par David :: #
L'utilisation de composer ne peut-elle pas résoudre ce genre de problème ? Chacun son rôle: git pour le versionning et composer pour les dépendances.
Le dimanche 11 octobre 2015 à 05:31, commentaire par 3po :: #
La raison derrière le fonctionnement des submodules est simple :
On doit pouvoir revenir à tout moment à une version particulière du dépôt. Si on mettait les submodules en "head" constamment une version mise en production ne pourrait pas être reliée à un commit particulier ce qui est mauvais du point de vue de la traçabilité du code (tout comme déclarer des dépendances en version snapshot).
Bien sûr si ce concept n'a pas d'importance pour vous, c'est sûrement mieux de rester sur subversion.
Notez qu'il est sûrement possible de simuler la récupération d'un dépôt en head après un update grâce à git hook.
Le lundi 12 octobre 2015 à 12:32, commentaire par perrick :: site :: #
Pouvoir "revenir à tout moment à une version particulière du dépôt", c'est bien bien. Mais ce n'est souvent pas suffisant : le roll-back sur une base de données n'est souvent pas une mince affaire. Des colonnes peuvent avoir disparus, des valeurs peuvent changer de format, etc. Bref c'est souvent impossible de satisfaire ce point-là.
L'important pour nous est donc de garantir la fiabilité des processus de mises à jour. C'est pourquoi l'outillage est très important, voir prioritaire. Nous l'avions sous-estimé ! Tout comme nous avions sous-estimé l'importance des choix conceptuels de Git : nous sommes tout simplement dans d'autres clous ;-)
Le lundi 12 octobre 2015 à 14:54, commentaire par 3po :: #
Effectivement, la base de données pause un problème pour un rollback éventuel. Néanmoins, le versionning sert rarement à faire un rollback de la base de données longtemps en arrière.
Par exemple, il est courant (là où je travaille) le lendemain d'une mise en production de reprendre une version backupé la veille pour comprendre ce qui s'est passé si il y a des régressions.
Le lundi 12 octobre 2015 à 15:12, commentaire par perrick :: site :: #
Dans ce cas, SVN aussi a un commande pour retrouver une version précise dans l'historique : "svn switch"
svnbook.red-bean.com/en/1...
Chez No Parking, les mises en production sont plutôt du genre quotidiennes : le delta est donc assez faible avec la version à mettre à jour. Et par conséquent les besoins de revenir à une version antérieure assez faible.
Le lundi 12 octobre 2015 à 16:11, commentaire par 3po :: #
Dans tous les cas, il y a une solution à ces problèmes dans Git et Subversion à mon avis.
La question que je me pose maintenant c'est si vous voulez que les deux projets ne fassent plus qu'un, pourquoi ne pas ne pas en faire qu'un dépôt justement ?
Le lundi 12 octobre 2015 à 16:36, commentaire par perrick :: site :: #
Continuons donc la partie de ping-pong...
Pourquoi pas un unique dépôt ? La raison est simple : si Opentime.fr correspond à 80% de nos clients, il en reste 20% pour lesquels nous faisons du spécifique. Pour ces clients, nous avons un autre coupe "Opentime + Plugin" qui fonctionne lui aussi via un svn:externals.
J'imagine que d'autres équipes de dev utilisent le couple "Git + Composer" ou des paquets liés à leur OS pour répondre à ce genre de problématique. Mais dans notre cas - petite équipe, maitrise complète sur l'ensemble du code, longue histoire - SVN s'est imposé naturellement. Et nous n'avons pas encore senti la nécessité de nous en affranchir.
Le lundi 12 octobre 2015 à 18:18, commentaire par 3po :: #
Ok j'essaye juste de comprendre vu que je ne comprend pas totalement la raison de la marche arrière de la transition que vous avez entamée.
Je comprend totalement que vous ne vouliez pas changer de gestionnaire de version si vous n'en avez pas besoin ou si les concepts de git ne sont pas en accord avec vos pratiques.
Le jeudi 15 octobre 2015 à 22:12, commentaire par perrick :: site :: #
@David : en effet, nous avons exploré Composer. Cette piste ne nous a pas complètement convaincu pour trois raisons.
1/ il n'est pas possible de faire un commit dans les bibliothèques importés depuis Composer (il faut à chaque fois, commiter dans le dépôt source puis ré-importer les mises à jour dans le dépôt du plugin).
2/ visiblement Composer ne propose pas d'installer les bibliothèques importés dans un endroit spécifique (il installe toujours tout au même endroit) : svn:externals est plus flexible de ce point de vue précis.
3/ cela voulait dire ajouter deux outils (Git + Composer) pour en remplacer un (SVN). Nous n'avons pas souhaité faire ce pas là.
Mais j'imagine bien que c'est un pas acceptable dans un tas de contexte, surtout si les bibliothèques importés sont gérés par une équipe tierce, et encore plus quand elles sont gérées dans une autre organisation (comme dans le cas des frameworks du marché en particulier). Parce que oui, nous n'utilisons pas de framework !
Ajouter un commentaire
Les commentaires pour ce billet sont fermés.