Tag - git - Simple IT : le blog

Tag - git

lundi 23 août 2010

Mise en ligne des nouveautés du SdZ avec Capistrano

Par Vincent Primault le lundi 23 août 2010, 16h40 - Technique

Note de Mathieu : comme nous l'avons signalé à toutes les personnes qui travaillent chez Simple IT, nous leur proposons d'intervenir de temps en temps sur le blog pour présenter les projets sur lesquels ils travaillent. Le but est de varier les sujets et les styles d'écriture en donnant la parole aux employés. Vincent Primault (alias vincent1870), développeur sur le Site du Zéro, est le premier à rédiger un tel billet. Vous le trouverez ci-dessous.

Depuis un an et le billet annonçant la fin du bricolage, de nombreuses choses ont encore évolué sur notre façon de travailler en interne. Ce billet est là pour présenter aux curieux les rouages de notre nouvelle méthodologie de développement, qui se veut plus professionnelle et adaptée à la taille grandissante de Simple IT et du code du site.

Retour sur les faits

Pour rappel, le site est depuis le début de l'année en plein chamboulement puisque nous sommes en train de porter tout le code vers le framework web symfony (dans sa version 1.4). Cette décision n'a pas été prise à la légère et permet d'assurer à terme plus de flexibilité dans le code et d'accélérer le développement de nouveaux modules en utilisant toute la batterie d'outils que symfony met à notre disposition.

Cette démarche de rationalisation du développement ne se résume cependant pas à l'adoption de symfony. Depuis le début de l'été, nous n'avons pas chômé, et plusieurs réflexions importantes ont été commencées concernant la façon même dont nous développons et les processus entourant l'écriture. Le reste de ce billet va traiter de la nouvelle organisation mise en place concernant la mise en ligne des nouveautés sur le Site du Zéro.

Git c'est bien

Comme vous le savez sans doute si vous avez lu les billets précédents, le code source du Site du Zéro est versionné via le logiciel Git. Cet outil indispensable pour nous permet de conserver une trace de toutes les modifications apportées au code du site, quand et par qui. L'outil est actuellement bien exploité, nous utilisons notamment beaucoup le système de branches qui nous permet de cloisonner nos développements et de pouvoir changer rapidement de sujet de travail sans rien perdre.

Si je parle de Git c'est qu'on l'utilise en fait actuellement presque trop, en sortant de ses attributions d'origine. C'est en effet lui qui nous permet actuellement de réaliser nos déploiements. Pour rappel, le déploiement est l'action consistant à faire passer du code de la machine d'un développeur vers le serveur de production, Lisa, qui dessert les pages que vous voyez tous les jours. Une fois le code déployé, tous les visiteurs y ont accès, c'est donc une étape essentielle ! Utiliser Git pour cela est très simple et rapide : il suffit de créer une copie du dépôt sur le serveur de production, de lancer la mise à jour des sources et tout est en ligne quasi-instantanément. Si cet usage est courant, il atteint cependant assez vite ses limites, comme nous nous en sommes rendu compte nous-mêmes.

En effet, depuis la mise en place de symfony, la procédure de mise en production a commencé à s'alourdir . Tout d'abord, il a fallu systématiquement nettoyer le cache de symfony en lançant une commande à l'issue de la mise à jour des sources. Cela peut sembler anodin, mais cela faisait une tâche de plus à la charge du développeur. Et il suffit de l'oublier pour que nos changements soient alors non fonctionnels, et qu'on perde alors du temps à trouver d'où vient le problème (c'est du vécu !).

Les problèmes ont continué lorsque récemment nous avons lancé le projet d'exploiter enfin correctement l'ORM fourni avec symfony (Doctrine) en utilisant ses migrations. En deux mots, c'est un outil très pratique permettant d'automatiser les modifications sur la base de données telles que l'ajout de colonnes ou de tables, avec des facilités telles l'annulation des modifications simplement. Cependant cela fait encore quelques commandes de plus à lancer à chaque déploiement, et ce sur la version de développement et de production. La démarche commençait alors à s'alourdir considérablement, nous avons donc cherché du côté d'outils permettant d'industrialiser ces manœuvres.

Capistrano c'est mieux

Je m'intéressais à ce type d'outils depuis un moment, et je lorgnais déjà de fait sur un outil bien précis, répondant au doux nom de Capistrano. Ces outils ne sont pas très nombreux, et ceux matures le sont encore moins. Capistrano est un outil codé en Ruby et assez réputé dans le domaine. Pour l'anecdote il est notamment utilisé par Twitter pour ses déploiements.

Il faut savoir que Capistrano n'est pas réellement un outil de déploiement, mais que ce n'est en fait qu'un outil de réplication de commandes sur un parc de serveurs. Pour l'instant nous n'avons qu'un serveur web de production, mais cela tombe bien car le jour où nous en aurons plus (ce qui arrivera fatalement un jour ou l'autre pour parer au trafic croissant du Site du Zéro) nous serons déjà prêts ! Actuellement nous nous en servons donc "juste" pour exécuter un jeu de commandes à la chaine.

Il est conçu à l'origine pour déployer des projets Ruby on Rails (un framework de développement web codé en Ruby) mais s'adapte très facilement à d'autres projets. Nous avons pour notre part largement repris la base fournie par le projet Capifony qui était une extension de Capistrano à des projets symfony. Adapter Capistrano nécessite juste de connaitre un peu le Ruby, mais cela se fait très bien. Pour tout dire je n'avais jamais touché au Ruby avant de devoir personnaliser Capistrano, et cela s'est très bien passé, les outils de base couplés à Capifony se laissent facilement prendre en main. Je regrette juste que le site de Capistrano soit un peu anarchique et qu'on ait du mal à trouver ce que l'on cherche.

Lors de ses déploiements, Capistrano conserve un historique de toutes les releases du produit. Cela permet par exemple de pouvoir revenir à une version antérieure de façon instantanée. Il gère également des ressources partagées entre toutes les versions, telles que des fichiers de configuration ou des uploads. Le déploiement en lui-même se fait de façon très simple en lançant une simple commande en console. Pour les curieux, cela donne en pratique une arborescence similaire à ce qui suit sur le serveur de production :

current
releases
- 20100820090035
- 20100822090214
shared
- config/databases.yml
- web/uploads
- log

Chaque sous-dossier dans le répertoire releases contient une extraction du code source de Git à une date donnée (indiquée par le nom du répertoire). current est en fait un simple lien pointant vers la dernière version (c'est pour ça que revenir en arrière est très simple, il suffit de changer le lien !). Enfin shared contient toutes les données partagées, avec par exemple les fichiers de configuration symfony, les uploads ou les logs.

Le serveur web va chercher le site dans current. Comme il s'agit d'un lien symbolique, il utilise en fait le code source de la release sur laquelle il pointe.

Et avec Webistrano...

Pour nous combler pleinement, nous voulions un outil capable d'enregistrer un détail de l'activité de déploiement et capable d'agir différemment en fonction de l'environnement ciblé. Capistrano à la base est flexible à volonté, mais ne permet pas forcément d'organiser son code de façon très propre, et réaliser une personnalisation en fonction de l'environnement ciblé aurait été assez compliqué à gérer pour quelqu'un qui ne connaissait que très peu le Ruby comme moi.

Une solution s'est alors naturellement imposée : Webistrano. C'est en fait une simple interface web (codée en Ruby on Rails) pour Capistrano. Les avantages sont alors multiples :

La configuration de l'outil se fait de façon très agréable. Cela ne dispense absolument pas de connaitre le fonctionnement de Capistrano mais c'est bien plus visuel que la version en Ruby.
L'outil gère de façon native la différenciation des environnements de déploiement (par exemple pour nous ceux de pré-production et celui de production).
Le code de personnalisation est bien mieux organisé, on a la possibilité de partager des bouts de code à travers les projets et les environnements.
Le déploiement se fait de façon graphique, on récupère les logs en temps réel.
Chaque déploiement est enregistré, on en garde une trace, et on peut très facilement revenir en arrière si quelque chose se passe mal.
Capistrano est exécuté sur le serveur hébergeant Webistrano, ce qui permet d'éviter à chaque développeur d'installer et configurer Capistrano en local. Tout est centralisé et partagé.

L'outil s'est jusqu'ici remarquablement bien comporté, s'avérant très ergonomique et surtout accélérant le temps passé à configurer Capistrano. Nous avons juste eu à le modifier très légèrement pour nos besoins, mais de façon très mineure (c'était principalement de l'adaptation pour symfony et un peu de personnalisation visuelle).

Une nouvelle rigueur dans le processus de développement

Tout cela nous amène à avoir une nouvelle rigueur dans le processus de déploiement. Actuellement l'intégration en production se fait tout au long de la journée par les développeurs. Ce processus devient peu gérable, les déploiements devant être planifiés. Nous allons donc progressivement tendre vers une rationalisation des déploiements, qui seront faits environ une fois par jour, à heure fixe, tout en gardant une certaine souplesse dans le cas d'une réelle urgence comme une correction de faille.

De plus, les environnements sont maintenant différenciés plus fortement. Nous exploitons un trio classique d'environnements :

La version de développement du site, qui est notre version locale. Chaque développeur travaille avec sa version du code et sa base de données. C'est sur cette version que les nouvelles fonctionnalités sont implémentées.
La version de pré-production du site (aussi appelée de recette) qui est une copie du site en ligne (hébergée sur les serveurs de Simple IT mais non accessible au public). Elle se comporte de façon identique en tout point à la production. Cela nous permet de prévenir au maximum les risques lors du moment fatidique.
La version de production, accessible à tous à l'adresse http://www.siteduzero.com, est le produit fini.

C'est une évolution de plus dans nos processus internes, et certainement pas la dernière. L'objectif est réellement d'automatiser au maximum de façon à décharger les développeurs des tâches répétitives. D'autres réflexions sur des sujets similaires sont dans les tuyaux, vous en saurez plus prochainement !

21 commentaires

mercredi 27 mai 2009

Quelques avantages et défauts de Git

Par Mathieu Nebra le mercredi 27 mai 2009, 16h15 - Technique

Voilà plusieurs semaines que nous sommes passés de SVN à Git au bureau et j'ai pensé qu'un petit point ici serait bien. En effet, j'ai remarqué qu'un certain nombre de développeurs avaient tendance à nous imiter : si on utilise telle bibliothèque, je découvre quelques semaines plus tard par hasard qu'elle suscite un intérêt soudain chez un certain nombre de visiteurs du site. De la même manière, j'ai appris récemment qu'il était probable que le site des zCorrecteurs passe à Git (attention, c'est une rumeur, je ne sais pas s'ils le feront ;o).

Cela réussit toutefois à m'inquiéter car, si je suis flatté de voir que l'on serve d'exemple pour certaines personnes, il ne faut pas le faire aveuglément. Aucun de nos choix n'est parfait, et il faut bien mesurer les conséquences de son acte avant de changer quelque chose d'aussi important qu'un système de versionnement.

Je voudrais donc ici apporter un oeil critique sur Git. Je souhaite mettre en exergue à la fois les points positifs et les points négatifs que l'on en retire. Bien entendu, tout ceci est extrêmement subjectif. Je sais que Git n'a pas été prévu pour fonctionner comme ceci ou comme cela, mais on en fait un usage bien particulier et je tiens à dire les avantages et défauts sur lesquels on est tombés.

Avantages

Le premier avantage, qui a été la première raison de notre migration, c'est sa gestion des branches. On peut enfin travailler sur plusieurs projets en parallèle sans se marcher sur les pieds. Nous avons donc commencé à utiliser intensivement cette fonctionnalité, et une fois qu'on a compris le fonctionnement c'est un vrai régal. C'est simple, ça marche, et on n'a pas à copier tout le projet comme avec SVN pour créer une branche.
L'interface console un poil plus évoluée que SVN. Ce sont des choses toutes simples, comme le fait qu'il fasse un "less" pour paginer automatiquement lorsqu'on affiche le log des commits. Ou la couleur, plutôt agréable, qu'il faut néanmoins activer au préalable.
Les algorithmes de fusion (merge) : quand un fichier a été modifié par plusieurs personnes en même temps, Git sait s'adapter et choisir un algorithme qui fusionne intelligemment les lignes du fichier qui ont été modifiées. Si par hasard 2 personnes ont modifié en même temps la même ligne (cas rare, mais qui arrive), il y a un conflit et Git laisse des marques dans le fichier pour dire qui a modifié quoi, et vous invite à décider ce que vous gardez.
La rapidité : lorsque vous vous mettez à jour, les données sont empaquetées, compressées, et les mises à jour sont fusionnées à la vitesse de la lumière, même s'il y a eu de très nombreuses modifications depuis la dernière fois. Cette rapidité m'étonne réellement à chaque fois.
Contrairement à SVN, Git ne surveille pas les fichiers mais leur contenu. Cela permet de faire des choses qui auraient été impossibles autrement, comme savoir qu'une fonction a été déplacée d'un fichier à un autre.

Défauts

La complexité : quoiqu'on en dise, ce n'est pas un outil à mettre entre les mains de n'importe qui. C'est fait par des développeurs pour des développeurs. SVN est vraiment facile à utiliser à côté. Cette impression est renforcée par le fait que les commandes ne sont pas intuitives. La même commande semble servir pour 2 choses très différentes (je pense à checkout, qui permet de changer de branche et de remettre à jour un fichier depuis le dernier commit). D'un point de vue du développeur, je suis persuadé que c'était logique et même élégant. Du point de vue de l'utilisateur, c'est une aberration. Voilà ce qui me fait dire que Git se soucie assez peu de la difficulté de prise en main. Il y avait une surcouche qui simplifiait un peu l'utilisation, mais je crois qu'elle a été abandonnée.
Le portage sous Windows est plutôt nul. Il faut utiliser cygwin. Heureusement, le projet msysgit permet d'avoir un installeur tout-en-un, mais je rencontre personnellement quelques difficultés : parfois, il ne veut plus se connecter au serveur par SSH, et ce sans raison apparente. Plus moyen de faire un pull... à moins de réinstaller msysgit. De plus, l'interface console n'est pas courante sous Windows. On est loin d'un TortoiseSVN par exemple. Certes, il existe TortoiseGit, mais il nécessite msysgit pour fonctionner. Enfin, les merges sont sensiblement plus lents sous Windows quand même.
Les retours à la ligne ont intérêt à être tous du même type (\n par exemple). En effet, si l'un de vos développeurs travaille avec un éditeur sous Windows qui est configuré pour créer des \r\n comme retours à la ligne, toutes les lignes d'un fichier seront considérées comme changées lorsqu'il l'éditera... d'où de nombreux conflits de merge. Là encore, c'est à mettre en liaison avec le fait que c'est plutôt fait pour être utilisé sous Linux. Si tout le monde a Linux, édite avec des \n, encode en UTF-8, alors oui, il n'y aura pas de problème. :D
Le très grand nombre de commandes qui existent. On peut se contenter de quelques-unes, mais on en découvre toujours de nouvelles, pas forcément très faciles ni très safe à utiliser. Il faut donc se méfier de ce qu'on fait. C'est à mettre en relation avec la complexité. Comme tout outil Unix, ça fait ce qu'on lui dit, même si on ne sait pas bien ce qu'on fait et qu'on débute (on n'a pas vraiment perdu de travail depuis le début, mais on a failli).

Maintenant ça va mieux, mais il a fallu un temps d'adaptation et pas mal de pédagogie pour que tout le monde l'utilise comme il faut. Ca ne s'utilise pas comme SVN, ça ne ressemble pas à SVN, ce n'est pas SVN. Sachez-le si vous comptez migrer : vous en retirerez de réels bénéfices, mais il faut que votre équipe soit constituée de développeurs, de préférence sous Linux, qui apprennent vite et qui sont habitués aux commandes Unix.

Ces listes ne sont pas exhaustives, je pourrais les compléter à l'occasion. Je pense néanmoins avoir dit l'essentiel pour donner grosso modo mon avis sur le sujet. :o)

18 commentaires

dimanche 3 mai 2009

La fin du bricolage

Par Mathieu Nebra le dimanche 3 mai 2009, 13h56 - Technique

Un mois s'est écoulé depuis le précédent billet. Ce silence s'explique avant tout pour 2 raisons :

La sortie du nouveau design New Wave, qui, comme toute mise en production qui se respecte, a demandé de nombreuses petites corrections de bugs dans les semaines qui ont suivi. On n'a pas fini, il reste toujours des choses à faire, mais au moins ça s'est calmé de ce côté-ci.
L'arrivée de 2 stagiaires, Willy et Nicolas, qui travaillent sur le développement du site : améliorations et corrections de bugs. Ils seront rejoint dès demain par Mathias, ce qui fait que nous serons 4 au bureau pendant les 2 mois à venir. J'aurai l'occasion de parler plus en détail de ce qu'on fait et de ce en quoi consiste mon / leur travail.

Des développeurs

Aussi étonnant que cela puisse paraître, le Site du Zéro a vu son trafic grossir ces dernières années, mais pas son nombre de développeurs. A temps plein, pour s'occuper du code, il y avait en moyenne entre 0 et 1 développeur, selon les jours. Or, on ne peut pas croire qu'un site comme celui-ci se suffit à lui-même : il y a tous les jours des problèmes différents à régler, de nouvelles fonctionnalités et des améliorations à effectuer que nous aimerions faire depuis un moment.

Pour le SdZ, je ne pense pas qu'il soit non plus nécessaire de lever une armée de développeurs. Mais il est clair que n'avoir personne, ou presque, pour s'en occuper est inadéquat. A l'heure actuelle, je pense qu'entre 2 et 3 développeurs (à temps plein) conviennent. C'est de toute façon difficile actuellement pour moi d'en manager plus que ça.

Des rapports de bugs

Où je veux en venir ? Quel rapport avec le titre "La fin du bricolage" ?

Justement, si j'estime que l'on faisait du "bricolage" avant, c'est précisément parce que n'avions pas vraiment évolué depuis les tous débuts de la version 3 du site. Un serveur de développement, un serveur de production. On teste les fonctionnalités sur la "copie" du site en développement, et dès que c'est bon on passe en production en copiant les fichiers.

Globalement, ça, c'est le B.A.-BA. Mais ce n'était plus suffisant. Nous avions toujours une gestion anarchique des rapports de bugs et des améliorations. Aujourd'hui, nous utilisons comme je l'ai déjà mentionné un bug tracker qui nous permet de mieux suivre ce qui se passe, de gérer les priorités et de savoir "qui est en train de faire quoi". Ca peut paraître bête, mais parfois on ne savait pas toujours bien ce qui était en train d'être développé sur le site. Aujourd'hui heureusement, on a une meilleure visibilité.

Concernant le développement, il a été ces dernières semaines décentralisé. Nous avons certes gardé le serveur de développement, mais nous travaillons avant tout en local.

Des branches

Enfin, et c'est ce qui m'a occupé ces 2 dernières semaines (et qui m'a rendu quasiment invisible) : nous avons changé de logiciel de versionnement. Nous sommes passés de SVN à GIT. Autant dire que le passage s'est un peu fait dans la douleur, tant ces outils (qui ont pourtant le même but en théorie) s'utilisent différemment. Il a fallu nous réhabituer et nous défaire de certaines habitudes.

Branches

Git est, en quelques mots pour ceux qui ne connaissent pas, un système qui nous permet de garder une version de chaque fichier. Chaque modification est enregistrée, et si on veut retrouver le fichier tel qu'il était il y a 6 mois, on peut. On peut savoir qui a modifié le fichier quand, et pour quelle raison. On peut savoir quelles lignes il a ajoutés ou retirées. SVN fait pareil. La différence essentielle à nos yeux qui a justifié la transition, c'est que Git gère les branches de manière beaucoup plus fine.

Une branche est une évolution en parallèle du code source du site. C'est un moyen de tester de nouvelles fonctionnalités, de nouvelles idées, sans risquer de casser la branche principale "qui marche". C'est seulement une fois que la branche est stable que l'on décide de la fusionner avec la branche principale.

Regardez par exemple l'image ci-contre. Elle se lit de bas en haut et représente l'évolution du code. Chaque point est un état à un moment donné du site. La ligne tout à gauche représente la branche principale. C'est le site dit stable, celui que vous voyez quand vous visitez le SdZ. Parfois, on fait dériver en parallèle le site pour tester d'autres fonctionnalités dont on n'est pas sûr du temps qu'elles peuvent prendre à être réalisées : ce sont les branches. Le site évolue en parallèle et, au bout d'un moment, cette évolution est fusionnée avec la branche principale car on la considère utilisable. C'est alors que vous voyez ces changements en production, sur le SdZ.

Il y aurait beaucoup à dire sur Git, le fait notamment qu'il soit décentralisé et ne nécessite pas de serveur. Ou le fait qu'il se soit révélé extrêmement rapide. Ou encore le fait que ce soit un outil vraiment tourné vers les utilisateurs Unix et, bien que ça fonctionne, ce n'est pas encore vraiment la joie sous Windows. Ca reste un outil délicat, très délicat à manipuler. Comme tout bon programme sous Unix, ça fait ce qu'on lui dit, même si on lui dit de faire n'importe quoi. On l'a découvert à nos dépens.

Git a été conçu notamment par Linus Torvalds et est utilisé pour le développement du Kernel de Linux. Pour le moment, ce n'est quand même pas un outil grand public car il expose aux utilisateurs des concepts relativement avancés. En clair, je n'en recommande pas l'usage pour un débutant, mais si votre équipe est constituée de bons développeurs qui ont l'habitude d'utiliser des commandes Unix, alors vous finirez par beaucoup y gagner.

Du temps libre, peut-être ?

Il y avait un temps où on ne savait pas qui faisait quoi, où on ne savait pas où en étaient les résolutions de bugs, où deux personnes pouvaient difficilement travailler en même temps, où il était difficile de tester une nouvelle idée sans risquer de la mettre en production par inadvertance. Ca, c'est ce que j'appelle le bricolage.

L'évolution en interne a été un peu dure, mais elle était nécessaire. Il valait mieux le faire maintenant que de traîner de toute façon.

Paradoxalement, ça m'a mangé à peu près tout mon temps depuis 2-3 semaines. J'espère commencer à pouvoir respirer un peu et pouvoir à nouveau m'occuper du coeur du site : son contenu. J'ai commencé la rédaction du prochain chapitre Linux et j'ai commencé à effectuer des corrections globales - mais ennuyeuses - sur le tutoriel de C. Rien de tout cela n'est encore visible, mais ça ne saurait tarder.

17 commentaires un rétrolien