Mise en ligne des nouveautés du SdZ avec Capistrano

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…

Accueil de 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 !

Commentaires ( 21 )

  1. Pour information, la très courte maintenance de ce matin (à peine quelques minutes) était justement dûe à la mise en place de Capistrano sur le serveur de production (« Lisa 2″, qui est notre nouveau Lisa).

    Tout s’est bien passé et nous avons pu en un clic mettre en production toutes nos dernières modifications sur le site. Désormais, les mises en prod ne nécessiteront plus de couper le site (à de très rares exceptions près et pour quelques secondes seulement), étant donné la façon dont Capistrano fonctionne, ce qui est très appréciable.

    Le billet est assez technique, mais il en faut pour tous les goûts ! Si vous avez des questions, je suis sûr que Vincent sera ravi de papoter avec vous. :p

  2. Voila un article qui m’intéresse beaucoup !
    Bravo Vincent :)

  3. Devoir vous appuyer sur des demi-douzaines d’outils externes différents, est-ce vraiment sûr ? Après tout, ces outils ont l’air très connus, donc si une faille est découverte sur l’un d’eux… multiplié par le nombre d’outils, ça fait « beaucoup » de risques non ?

  4. Excellent billet merci pour les infos :-)

  5. Il y a un moment où on est obligés d’arrêter de réinventer la roue et de se servir de ce qu’on a à notre disposition. Oui ça multiplie les failles potentielles, c’est obligé, mais les outils qu’on choisit sont matures et maintenus. C’est comme si on avait peur d’utiliser Git parce qu’il est peut-être buggé et qu’on préférait le recoder nous-mêmes quoi. :D Le résultat serait sans nul doute bien pire.

    Là en l’occurrence pour Capistrano les risques sont minimes puisque c’est vraiment juste un outil interne.

  6. @Diti : si tu pars de ce principe, tu ne développeras jamais rien ^^
    Justement si ces produits ont atteint une telle nototriété, c’est pour leur efficacité et leur sécurité. en général, beaucoup de personnes ont participé donc toutes les failles ont pu être prévenues…

    On peur prendre par exemple Symfony. Il est bien plus sûr d’utiliser les fonctions de Symfony pour ajouter des objets en base plutôt que de coder sa propre fonction :p

  7. Encore un excellent article, mais encore une fois je me demande si ce que vous faites est fait au bon temps. Oui il faut faire évoluer le côté de gestion au même rythme que l’expansion de l’entreprise, mais ne le faites vous pas un peu trop tôt? Il y a tant d’autres aspects plus important dans votre développement! Était-ce si invivable de la façon que vous procédiez? J’ai juste l’impression que vous déployez trop d’efforts (aussi utiles puissent-ils être à long terme) trop tôt, ce qui vous ralenti.

    Mais bon, comment vous en vouloir? Vous avez bien le droit de gérer comme vous le voulez après-tout :)

    Bonne chance pour la suite et au prochain article!

  8. Ah un nouvel outil intéressant que je n’ai pas essayé :) je vais me renseigner sur son utilisation !

    @MmAxX : quel aspets plus importants y a t’il ?

  9. Coup de chapeau à Vincent autant pour la rédaction de l’article que pour le travail de mise en place de l’appli.

    @MmAxX : La situation de travail évolue, et les besoins, même si il ne sont pas titanesques, sont croissants. je vois 2 options :
    Soit prendre une solution dimensionnée uniquement à nos besoins actuels, Soit prendre une solution sur-dimensionné pour éviter de traîter un problème plusieurs fois.

    S’agissant du retour sur investissement, la seconde solution paraît évidente. Les procédures de Capistrano/Webistrano se sont avérées exagérément puissantes pour un temps de veille/d’installation acceptable.

    Est-ce qu’il dépasse nos besoins ? oui. Est-ce qu’il répondra à tous nos besoins sur le long terme, sûrement. Est-ce qu’immédiatement il répond à nos besoins précis ? oui.
    Je trouve que c’est un bon combo gagnant.

  10. Très intéressant ce billet, on sait quels outils sont utilisés pour des sites tels que le Site du Zéro.
    D’ailleurs, je ne parviens plus à me souvenir du nom de celui en place sur dev.zcorrecteurs.fr (un htaccess a été installé depuis, on n’y a plus accès).

    N.B. : maintenant on sait pourquoi Vincent pleurait mercredi dernier (tweet de mathieu : Le pauvre Vincent pleure dans la pièce d’à côté : il essaie d’installer un simple outil en Ruby ! Pas facile avec les Rubygems) ou pourquoi il lui était venu à l’esprit de se pendre avec un RJ45. :D

  11. Bel et puissant outil que vous avez décidé d’utiliser là !

    Très bon billet, Bravo Vincent.

  12. Un doliprane plus tard => J’ai l’air malin avec mon filezilla maintenant !

  13. Super article. Je suis devenu un inconditionnel de votre blog, j’y apprend chaque fois plein de choses ! Merci encore pour l’esprit de partage du SdZ.
    Chapeau pour le travail accompli, votre aventure est un bel exemple.

  14. Je trouve quand même que Capistrano est un peu superflu, et voilà pourquoi :

    Pourquoi conserver les releases du SdZ ? C’est inutile, vu que git sait déjà le faire. Il suffit de faire un tag et de checkout plus tard… Quand au lien symbolique current, il est aussi pas très utile, vu qu’il suffit de se placer sur la branche master (ou n’importe laquelle) et de merge que quand les fonctionnalités sont prêtes. Et si ça marche pas, on revient à l’ancienne version avec reset ou checkout.

    Pour ce qui est des commandes à exécuter entre les releases, je ne vois pas pourquoi l’utilisation des hooks de git ne serait pas adaptée, puisqu’ils peuvent exécuter des commandes avant ou après à peu près n’importe quelle action (un push ou un pull, par exemple). Et si ça n’est pas adapté non plus, je ne vois pas pourquoi de simples scripts shells dans le répo pour automatiser les tâches ne conviendraient pas.

    Je suis sûr que vous avez vos raisons, mais en tout cas je trouve que vous ne les montrez pas du tout. Parce que git est un outil très puissant et très scalable. Et rajouter une couche par dessus tout ça est risqué (plus compliqué à maintenir, source potentielle de problèmes).

  15. Le fait est que comme je l’ai souligné dans le billet, Git n’est pas conçu pour effectuer des déploiements. On s’est servis pendant très longtemps de cet outil pour cet usage, mais on maintenant atteint les limites. L’utilité des releases n’est pas de remplacer Git, mais juste de conserver des snapshots des versions de production et de pouvoir y revenir bien plus facilement qu’en se disant « je reviens à la révision ab54f6cd » par exemple.

    Concernant les commandes, on pourrait faire des scripts bash oui (les hooks ne sont pas adaptés), mais outre le fait que la syntaxe est vraiment ingrate, on a des besoins vraiment fins qui impliqueraient une multiplication des scripts (différenciation des environnements, savoir si on fait un déploiement avec ou sans migration de la base de données par exemple). Sans compter qu’il y a une problématique qui n’est pas prise en compte là : la réplication des commandes. Capistrano est avant tout un outil de réplication de commandes, donc on prépare l’avenir. Le jour où on aura trois serveurs web, il sera impensable de se connecter sur chacun, de lancer les scripts et de se déconnecter.

    Enfin Webistrano fournit quelques outils très pratiques qui seraient dur à gérer autrement : il enregistre chaque déploiement, avec un commentaire indiquant les principales modifications, la date, l’auteur, et log en outre les retours des serveurs de façon très complète. De plus la configuration se fait de façon vraiment très simple et agréable. Je peux te dire que Ludovic (qui gère les déploiements actuellement) est vraiment plus serein au moment de mettre en production, car il sait que le processus est maitrisé et sécurisé. On a mis quelques jours à apprivoiser le système, on aura sans doute encore des ajustements à faire, mais par rapport à avant c’est juste pas comparable !

  16. Artefact : le fonctionnement que tu décris est plus ou moins celui que nous avions avant et duquel nous avons décidé de changer. Bien entendu, il est toujours possible de jouer avec les post-commit hooks, mais à un stade il devient nécessaire d’utiliser un outil qui soit vraiment conçu pour le besoin en question : le déploiement. Le post-commit hook n’est pas un moyen de déployer sérieusement une application à mon sens. Bien entendu, sur pas mal de petits projets c’est sûrement tout à fait acceptable, mais ça le devenait moins dans notre cas.

    L’idée derrière Capistrano est de logger nos déploiements : qui a déployé quand, à quelle heure et pourquoi. Le but est d’avoir une trace, et que l’outil soit assez flexible pour gérer toute la logique de déploiement qui s’est pas mal complexifiée ces derniers temps. Je ne crois pas qu’un git checkout / reset hard soit instantané par exemple, or avoir à un instant donné des fichiers de 2 releases différentes peut amener à des comportements tout à fait inattendus. Encore une fois, c’est acceptable un temps, mais au bout d’un moment ça ne l’est plus.

    Capistrano nous aide à rationaliser nos déploiements et à adopter une vraie logique projet. C’est avant tout pour cela qu’on en a besoin.

  17. Quote :
    « Je peux te dire que Ludovic (qui gère les déploiements actuellement) est vraiment plus serein au moment de mettre en production »

    Ca se voit tant que ça ? :)
    C’est un avis personnel : une solution de déploiement dans l’industrialisation d’un projet app web est juste indispensable.
    Chaque outil répond à un besoin. Git n’est pas un outil de déploiement. Capistrano en est un. (la réponse paraît succincte, mais je soutiens l’essentiel des arguments précédents).

  18. Très bon billet, un peu trop technique à mon goût, mais bon quand même.

    > « 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. »
    Ca veut dire qu’on peut faire plusieurs MAJ’s dans le code, mais mettre à jour une fois seulement ? Cool :D

  19. On pouvait déjà mettre en ligne plusieurs nouveautés d’un coup avant. Là ce n’est pas lié à l’outil mais plutôt aux processus internes à l’entreprise (qu’on a profité pour faire évoluer avec l’outil). Au lieu d’intégrer toute la journée les modifications, on le fait une fois par jour, de façon contrôlée. Le processus est donc plus mâture, rigoureux et sûr, pour nous comme pour vous !

  20. On-t-on accés nous, visiteurs, à la liste des nouveautés misse en production ? Si non, est ce que c’est prevu ?

  21. Non, l’outil de mise en production (Webistrano) est à usage interne des développeurs uniquement. Pour te tenir au courant de ce qui est fait, tu as le bug tracker et le forum Suggestions & commentaires sur le SdZ, avec ce sujet en particulier tenu à jour par notre Community Manager récapitulant les suggestions implémentées

    De plus les nouveautés vraiment importantes sont mises en valeur, par une news par exemple. ;)

Les commentaires sont fermés.