Git-deliver

Posté par . Édité par Xavier Claude, Benoît Sibaud, Nils Ratusznik, Bruno Michel et palm123. Modéré par Nils Ratusznik. Licence CC by-sa
49
21
août
2013
Gestion de versions

Git-deliver est un système simple et sécurisé sous GPLv3 pour :

  • déployer un logiciel sur un ou plusieurs serveurs ;
  • vérifier quelle version est sur un serveur, qui l'a livré et quand, et les éventuelles modifications depuis la livraison ;
  • partager des configurations de livraison.

Git-deliver s'appuie sur les atouts de :

  • Git pour la gestion des versions, le transfert de données et le contrôle d'intégrité ;
  • SSH pour l'authentification et l'exécution à distance de commandes ;
  • Bash pour l'exécution de scripts de livraison.

Un prototype fonctionnel se trouve sur Github, ainsi que plus d'informations et de documentation.

Contrairement à un simple Git push/checkout, Git-deliver :

  • rend la livraison « atomique » ;
  • structure la livraison en étapes et gère les erreurs tout en maintenant la disponibilité du logiciel ;
  • archive les livraisons et automatise les retours en arrière (« rollback ») ;
  • garde un journal des opérations ;
  • fournit une façon simple de savoir quelle version est livrée sur quel serveur, de valider l'intégrité des livraisons, et de savoir quand et par qui une version a été livrée ;
  • prévoit d'intégrer des recettes de livraison préfabriquées pour les environnements les plus courants.

Git-deliver utilise sur chacun des serveurs de destination un dépôt Git « bare » (sans copie de travail). Après la première livraison, un répertoire « delivered » y est ajouté, aux cotés des autres répertoires d'un dépôt Git traditionnel.

Ce répertoire « delivered » contient un clone Git du projet pour chaque livraison (les métadonnées sont partagées avec le dépôt principal pour limiter l'espace disque nécessaire). De cette manière, chaque livraison apparait comme un dépôt Git normal, sur lequel on peut utiliser git diff, git log, etc. pour obtenir des informations au besoin. Un lien symbolique « current » pointe vers la livraison en cours. Il permet d'avoir un chemin d'accès fixe vers la version actuelle du projet, et son changement de destination à la fin d'une livraison permet à la livraison d'apparaitre comme « atomique ».

Les anciennes versions du projet étant conservées jusqu'à suppression volontaire (via git deliver --gc ou manuellement sur le serveur), on peut revenir (avec git deliver --rollback) à une ancienne version facilement.

Une livraison est divisée en étapes, les « stages ». Chacun des stages peut faire l'objet de scripts Bash personnalisés pour inclure par exemple une migration de base de données, un vidage de cache, etc. Les jeux de scripts personnalisés peuvent être regroupés en « presets » pour être distribués. Ainsi, on pourrait par exemple avoir un preset « rails » servant de base pour toutes les livraisons Ruby On Rails, des presets « drupal », « wordpress », etc.

En cas de problème lors d'une livraison, soit dans les scripts personnalisés, soit dans le processus Git-deliver lui même, la livraison est abandonnée proprement, et le serveur est maintenu sur l'ancienne version.

Quelques exemples de commandes Git-deliver :

$ git deliver --init rails # initialise git-deliver pour un projet Ruby on Rails
$ git add .deliver && git commit -m "Config git-deliver" # commit la configuration git-deliver
$ git deliver test master # livre le dernier commit de la "branche" master sur la remote "test"
$ git deliver prod master # idem sur la remote "prod"
$ git deliver --status # indique quelle version est livrée sur chacune de nos remotes, qui l'a livré et quand, et s'il y a eu des modifications
$ git deliver --status prod # liste toutes les versions livrées sur "prod" et encore présentes
$ git deliver --gc prod # supprimme de "prod" les anciennes versions livrées (seules les trois dernières sont conservées)

Une campagne est en cours sur Indiegogo pour financer la suite du développement du projet.

  • # Excellent !

    Posté par (page perso) . Évalué à 4.

    Je suis en train de faire un bricolage en bash pour couvrir exactement ce besoin (mais nous en interne, on fait du mercurial dommage !).

    La livraison d'un logiciel sur un serveur est souvent complètement sous-estimée en terme de difficulté, archivage, vérification, etc etc. Surtout quand tu as envie de faire des livraisons fréquentes - cas assez courant dans les applis web.

    Donc un outil est le bienvenue, de mon point de vue, dommage que ce soit du git et pas autre chose.

    L'autre solution que je regarde de plus près, c'est de faire du PAAS mais l'offre française sur le sujet est très limitée.

    • [^] # Re: Excellent !

      Posté par . Évalué à 1.

      Je présume que le fonctionnement ne doit pas être trop différent sur mercurial, du coup il y aurait facilement moyen d'ajouter la prise en charge

  • # Multi-servers ?

    Posté par . Évalué à 3.

    J'ai peut être raté l'information mais je ne voit aucune mention de la possibilité de déploiement simultané sur plusieurs serveurs, chose indispensable dans un environnement avec répartiteur de charge (load balancing).

    Aussi, je me pose honnêtement la question des avantages d'une intégration à Git par rapport à un outil spécifique tel que capistrano.

    • [^] # Re: Multi-servers ?

      Posté par . Évalué à 2.

      On peut assez facilement ajouter le support multi-serveurs avec des scripts de livraison Git-deliver (un rsync en post-symlink par exmple). Il me semble difficile de l'intégrer dans l'outil directement tout en tenant compte de la diversité des systèmes, mais je prévois d'étudier la question. Les "remote groups" de Git peuvent être intéressants pour cela.

      • [^] # Re: Multi-servers ?

        Posté par . Évalué à 3.

        Effectivement rsync c'est souvent la solution qu'on trouve souvent dans les script Capistrano, Phing, Fabric et pas mal d'autres outil de déploiement/automatisation du même genre.
        Sinon c'est un outil intéressant pour ceux qui cherche une solution en Bash pour effectuer ce type de tâche mais c'est vrai que ça me semble aussi assez proche de ce qui est souvent fait avec les logiciels cités plus haut.

      • [^] # Re: Multi-servers ?

        Posté par . Évalué à 3.

        Il me semble difficile de l'intégrer dans l'outil directement tout en tenant compte de la diversité des systèmes

        Il n'est pas nécessaire de la prendre en compte. Ça peut être fait par l'utilisateur, mais surtout souvent les machines sont des clones les unes des autres ça permet de gérer plus facilement les choses.

        S'il n'est pas possible de regrouper les machines, je trouve que c'est vraiment un gros manque.

        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • # Campagne

    Posté par . Évalué à 2.

    Dommage que cet article n'est publié que maintenant, il ne reste plus que 5 jours de campagne :(

  • # Et dans l'autre sens ?

    Posté par (page perso) . Évalué à 2.

    Si j'ai bien compris le truc, les mises à jour sont poussées vers les machines "clientes".

    Existe-t-il un mécanisme pour un "pull", c'est-à-dire que ce soit les machines clientes qui viennent interroger le serveur ? J'en aurais eu besoin pour un de mes projets :) Du coup, j'ai bien le mécanisme de pull, mais pas la gestion des versions permettant de revenir en arrière (pour cela, il faut que je publie une mise à jour sur le serveur qui soit en fait une publication antérieure). Mais je le gère coté serveur, alors qu'avoir une gestion côté client aurait des avantages (par exemple, dans le cas où la nouvelle version bug au niveau réseau)

    • [^] # Re: Et dans l'autre sens ?

      Posté par . Évalué à 1.

      Ce n'est pas prévu, mais Git-deliver supporte les livraisons locales. Une astuce pourrait consister a déclencher une livraison locale sur les clients après pull.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.