Dispak : Gestion et déploiement de tags/branches Git + serveurs/services

Après Arkiv (dont je vous avais parlé dans un précédent article), voici un nouvel outil que j’ai développé pour mes besoins et que je publie sous licence libre : Dispak

Mon besoin était :

• Créer facilement des tags sur un repository Git, en effectuant un certain nombre de vérifications et actions automatiques (état du repo, minification de fichiers JS/CSS, envoi de fichiers statiques sur Amazon S3, …).
• Déployer les tags sur mes serveurs, là aussi en automatisant des choses (génération de fichiers de configuration, migration de schéma de base de données, installation de crontab, installation de fichiers de configuration Apache, …).

Et je voulais deux choses en plus :

• Afficher la liste des tags de manière plus pratique que ce qu’offre Git.
• Gérer les branches : les créer (en local et en distant), les effacer, les merger sur le master, et backporter les nouveautés du master vers les branches.

Je voulais aussi pouvoir ajouter facilement des fonctionnalités supplémentaires, pour éviter d’avoir plein de scripts qui se baladent dans tous les coins (qu’il s’agisse d’ajouter un utilisateur dans ma base de données, générer de la documentation à partir du code, effacer des fichiers temporaires, redémarrer des services sous certaines conditions, etc.).

N’hésitez pas à aller lire la documentation complète sur GitHub et à installer Dispak.

La genèse

J’avais commencé à gérer tout ça avec un fichier Makefile. J’utilise beaucoup les Makefiles, et pas seulement pour compiler du code source. C’est très pratique dès que vous voulez faire un script shell qui peut prendre des options sur la ligne de commandes. Et encore plus pratique pour centraliser plusieurs actions qui seraient habituellement séparées en plusieurs scripts.
Mais assez rapidement, je me suis retrouvé avec un très gros fichier, et même si j’avais trouvé un moyen pour mutualiser le code (des règles « privées » qui sont appelées par plusieurs règles « publiques »), ça devenait un peu acrobatique. C’est là que je me suis dit qu’un vrai outil serait préférable.

J’ai défini le périmètre :

• Je voulais faire un outil vraiment portable, donc pas développé dans un langage de programmation de haut niveau dont l’interpréteur n’est pas forcément présent. Naturellement, j’en suis venu au shell. Par contre, je me suis quand même autorisé à utiliser le bash qui offre pas mal de facilitées bien utiles tout en étant très répandu.
• Je voulais pouvoir facilement ajouter de nouvelles fonctionnalités à l’outil, que ce soit de manière globale ou individuellement par projet de développement. Cela a conduit à le rendre modulaire, avec une attention particulière sur la simplicité d’écriture des modules.
• Je me suis autorisé certains choix quant à la manière de gérer les types de plates-formes, la normalisation des tags, la manière de gérer les migrations de bases de données, ou encore les logiciels utilisés. Je vais revenir sur ces différents points.

Concepts-clés

Dispak utilise la gestion sémantique de versions et la numérotation impaire pour les versions instables.
Les tags sont donc nommés sous la forme X.Y.Z :

• X : Numéro de version majeure. Dois être incrémenté en cas d’évolution importante ou lorsque la compatibilité descendante n’est plus assurée.
• Y : Numéro de version mineure. Dois être incrémenté pour chaque évolution de fonctionnalité.
  • Les numéros pairs (0, 2, 4, …) sont utilisés pour les versions stables.
  • Les numéros impairs (1, 3, 5, …) sont utilisés pour les versions instables.
• Z : Numéro de révision. Dois être incrémenté lors de résolutions de bugs.

Dispak gère 3 types de plates-formes :

• dev : Poste de développement
• test : Serveur de test/staging/pré-production
• prod : Serveur de production

La plate-forme est détectée automatiquement à partir du nom de la machine, ou peut être indiquée dans un fichier de configuration. Si la machine est nommée ‘test‘ suivi de chiffres, elle est considérée comme un serveur de test ; si son nom commence par ‘prod‘, ‘web‘, ‘db‘, ‘cron‘, ‘worker‘, ‘front‘ ou ‘back‘ (suivi de chiffres), c’est un serveur de production ; autrement on la considère comme un poste de développement.

Seules les versions stables peuvent être installées en production. Les versions instables ne peuvent être installées qu’en test/pré-production uniquement. C’est une sécurité qui peut être très utile.
De la même manière, la fonctionnalité de copie des fichiers statiques vers Amazon S3 n’est exécutée que pour les tags stables (mais peut être forcée via le fichier de configuration).

Fonctionnalités de base

Affichage de l’aide

Cliquez pour agrandir

Lister les tags d’un projet en version succincte

Cliquez pour agrandir

Liste des tags en version détaillée

Cliquez pour agrandir

Création de tags

La création de tags suit plusieurs étapes (certaines étant optionnelles) :

• Suggestion du numéro de version (ou vérification si un numéro est fourni).
• Vérification de la branche et des fichiers non commités ou non poussés.
• Exécution de scripts de pré-packaging.
• Commit du fichier de migration de base de données.
• Minification JS/CSS.
• Envoi des fichiers statiques sur Amazon S3.
• Exécution de scripts de post-packaging.

Déploiement de tags

L’installation d’une nouvelle version automatise le process suivant :

• Vérification qu’un tag instable n’est pas déployé en production.
• Exécution de scripts pré-installation.
• Installation de fichier crontab.
• Migration de schéma de base de données.
• Installation de fichiers de configuration Apache.
• Gestion des droits d’accès aux fichiers.
• Exécution de scripts post-installation.

Gestion des branches

Dispak offre en plus quelques raccourcis par-dessus Git :

• Création de branches : Les branches sont toujours créées à partir de la branche master, soit depuis son état courant, soit depuis un tag donné.
• Effacement de branches
• Merge : Pour rapatrier sur le master les évolutions d’une branche.
• Backport : Pour récupérer sur une branche les dernières nouveautés du master.

Ajout de fonctionnalités

Il est très facile d’ajouter des modules supplémentaires, qui peuvent être soit utilisables pour tous les projets (en plaçant le module dans le répertoire d’installation de Dispak), soit juste pour un projet particulier (en mettant le module dans l’arborescence du projet).

Il suffit de créer un petit fichier en shell Bash dont la version minimale ne contient qu’une variable et deux fonctions (l’une pour l’affichage de l’aide, l’autre pour l’exécution du module).

Voici un exemple très rapide (détaillé dans la documentation) :

#!/bin/bash

# Rule's name.
RULE_NAME="minimal"

# Show help for this rule.
rule_help_minimal() {
	echo "   dpk $(ansi bold)minimal$(ansi reset)"
	echo "       $(ansi dim)Minimal rule that displays the current user login.$(ansi reset)"
}

# Execution of the rule
rule_exec_minimal() {
	echo "Current user login: " $(id -un)
}

Pour un usage plus avancé, le module peut attendre des paramètres sur la ligne de commande, qui peuvent être obligatoires ou optionnels ; Dispak se charge alors de vérifier que tous les paramètres obligatoires sont bien fournis, et qu’il n’y a aucun paramètre non attendu.

Une vingtaine de fonctions shell sont utilisables. Il y a des fonctions servant à l’affichage des données, d’autres facilitant les vérifications (on est sur une branche/le master, tous les fichiers ont été commités/poussés, …), la récupération de données (branche courante, tag courant, prochain numéro de version, …) ou encore le traitement général (affichage de message d’alerte, arrêt des traitements, etc.).

La documentation est assez complète, vous verrez qu’il est vraiment facile de créer des modules supplémentaires. Si vous n’êtes pas fan des scripts shell, vous pouvez faire un code minimal qui se contentera d’appeler vos programmes externes.