Mettre en place une Review App d'application statique
J’ai décidé d’écrire une série de quelques billets sur la gestion des Review Apps. Ces dernières représentent aujourd’hui une partie du Saint Graal des équipes de développement et DevOps. Le concept de Review Apps a été popularisé par Gitlab et consiste à déployer automatiquement du code applicatif depuis une branche de développement. Cela permet entre autres, de pouvoir tester une fonctionnalité avant d’intégrer le code de cette dernière dans une branche de production. La boucle de feedback est alors réduite à son maximum puisqu’il est possible de tester un développement pendant sa réalisation. Dans ce billet, nous allons nous intéresser au cas le plus simple de déploiement d’une Review Apps, à savoir déployer une application web statique.
Commençons tout d’abord par expliquer concrêtement ce qui va être mis en place. Lorsque nous écrivons du code, nous travaillons généralement sur une branche (d’un système de versionning) dédiée. Une fois notre développement terminé, le code est revu, validé puis intégré dans une branche de production commune à toute l’équipe. L’objectif de la mise en place de notre Review App sera de créer un environnement fonctionnel de notre application qui sera rattaché à la branche de travail du développeur. Cela va se traduire par un déploiement de la branche qui sera accessible via une adresse de type application.[nom-de-la-branche].domaine.tld.
Avant toute chose, je vais partir du principe que nous avons déjà une machine en place, configurée et opérationnelle avec un serveur HTTP installé. Dans ce billet, j’utiliserai NGINX, mais le principe est transposable sur n’importe quel autre serveur. Je suppose également que les DNS de votre domaine est également déjà configuré de manière à ce que les requêtes vers application.*.domaine.tld soit redirigé vers le serveur HTTP qui va accueillir notre Review App.
Maintenant que ces prérequis sont en place, attaquons le vif du sujet. Nous allons tout d’abird configurer le serveur HTTP pour que les requêtes de type application.[nom-de-la-branche].domaine.tld accède aux sources présentes dans le dossier suivant le motif /var/www/application/[nom-de-la-branche]. Avec NGINX, cela se fait relativement simplement en configurant la directive server_name au travers d’une expression régulière:
server {
listen 80;
server_name ~^application.(?<sname>.+?).domaine.tld$;
root /var/www/application/$sname;
index index.html;
}Une fois la configuration du serveur HTTP réalisé, nous allons nous occuper du déploiement de l’application. Cette dernière étant statique (c’est par exemple le cas de ce blog qui est généré par Jekyll), nous pouvons imaginer d’utiliser une commande telle que rsync pour copier les fichiers source dans le répertoire qui doit accueillir notre Review App. Cette commande serait idéalement lancer par votre CI (si vous en avez une), par un webhook configuré au travers de votre gestionnaire de code source ou (mais je ne vous le souhaite pas) à la main.
Pour ma part, j’utilise un script Bash prenant 2 paramètres en entrée: l’adresse du serveur sur lequel je souhaite déployer mon code et le dossier de destination. Le script s’assure alors que le dossier de destination existe, en le créant à défaut et effectue ensuite la copie des fichiers. Une version simplifiée de ce dernier pourrait ressembler à:
#!/bin/bash
HOST=$1
DIR=$2
ssh user@$HOST "mkdir -p $DIR"
rsync -azv dist/ user@$HOST:$DIRLa gestion de notre Review App est presque terminée. Il ne faudra pas oublier de gérer le cycle de vie de cette dernière, en synchronisant les fichiers lors de la mise à jour de la branche et de supprimer le dossier de travail lors de la suppression de la branche (ou de la validation de la merge request).
Et voilà, ce n’est pas plus compliqué que cela ! Si le terme de Review Apps peut faire peur et sembler complexe, il est possible de mettre en place des solutions simples, rapides et efficaces. Nous verrons dans un prochain billet comment mettre en place ce système avec une application nécessitant une base de données.