Git-deliver

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.

Aller plus loin

• La campagne Indiegogo (411 clics)
• Le projet sur Github (387 clics)