Faire une Review App avec CleverCloud et GitLab CI
Alors, d’abord, c’est quoi une Review App?
Voici ma définition: c’est la possibilité de pouvoir lorsque l’on fait une merge request (ou une pull request) de déployer dans un environnement distinct de la production ou de développement (mais similaire) une instance de l’application correspondant au code de sa MR (ou PR). Autrement dit, c’est pouvoir tester l’application avec vos modifications, sans “embêter” le reste de l’équipe.
Logiquement c’est votre outil de CI qui va vous permettre de faire ça.
J’ai un démonstration de WebApp dont je me sers pour expliquer le fonctionnement de Clever Cloud et j’ai mis en place un système de pipeline avec GitLab CI qui me permet de faire ça. Si vous voulez en savoir plus sur les Review Apps, allez jeter coup d’oeil par ici https://about.gitlab.com/features/review-apps/. Si vous voulez savoir comment faire avec Clever Cloud, il faut lire la suite de cet article.
Pré-requis
- Il vous faut une application dans un projet (repository) GitLab (ou sur GitLab.com ou sur votre propre instance de GitLab)
- Il faut que vous ayez déployé une 1ère fois votre application sur Clever Cloud. Notez l’id de l’application et l’id de l’organisation à laquelle elle appartient.
- Il vous faut un runner GitLab (le mien est un runner de type shell qui tourne sur Clever Cloud, mais une bonne vieille VM, un container ou les shared runners de GitLab peuvent faire l’affaire)
- Il faut créer puis déclarer votre runner dans votre projet (explications par ici https://docs.gitlab.com/runner/#install-gitlab-runner ou vous pouvez aussi vous inspirer de cet article par votre serviteur: https://medium.com/@k33g_org/d%C3%A9ployer-un-runner-gitlab-sur-clever-cloud-2a804d00d1ab)
Paramétrez votre projet
Allez dans les paramètres CI/CD de votre projet (dans GitLab), déroulez la rubrique “Secret Variables”, et renseignez les variables suivantes:
Où APP_ID
est l’id de l’application chez Clever Cloud, APP_NAME
le nom de l’application, ORGANIZATION_ID
l’id de l’organisation, ORGANIZATION_NAME
le nom de l’organisation, et CLEVER_SECRET
et CLEVER_TOKEN
les informations qui permettent à la CLI Clever Cloud de se connecter et interagir avec la plateforme (un peu d’information sur la CLI: https://www.clever-cloud.com/doc/clever-tools/getting_started/).
Si vous ne savez pas où trouver allez faire un tour ici ~/.config/clever-cloud
.
On y est presque…
La dernière chose qui vous reste à faire est d’ajouter à la racine de votre projet un fichier .gitlab-ci.yaml
qui va “dicter” à votre runner tout ce qu’il doit faire.
Mon application est une application Node.js et voici à quoi ressemble mon fichier .gitlab-ci.yaml
:
Les parties test et build ne sont pas importantes pour cet article (je n’ai pas dit qu’il ne fallait pas tester)
La partie “🚢 deploy_prod”
Cette partie explique à GitLab CI que à chaque fois que l’on merge sur master et seulement sur master(only: /master/
), on déploie le nouveau code sur Clever Cloud, vous pouvez lire dans la partie script, les commandes passées à la CLI Clever Cloud:
La partie “🦄deploy_tmp_vm”
Cette partie va permettre de proposer lors d’une merge request une étape (de déploiement) supplémentaire exécutable manuellement (when: manual
) sur un environnement à chaque fois différent (avec l’utilisation de $CI_COMMIT_REF_NAME
) et avec une url spécifique à chaque commit (avec l’utilisation de $APP_NAME
et $CI_COMMIT_REF_SLUG
), et uniquement lorsque l’on n’est pas sur la branche master (except: -master
),
Et de la même façon nous pourrons stopper et supprimer la VM déployée.
La partie “🗑destroy_vm”
C’est le même principe que l’étape précédente (sauf que dans ce cas les commandes passées à la CLI Clever Cloud servent à supprimer la VM)
Et maintenant, on s’en sert
Je crée une MR à partir d’une modification de mon code, ce qui déclenche un pipeline:
Je clique sur l’id du pipeline et vous pouvez voir que j’ai 2 jobs manuels deploy_feature et destroy:
Si je clique sur deploy_feature cela déclenche le provisioning d’une nouvelle VM chez Clever Cloud que vous pouvez suivre “à distance” dans l’IHM GitLab:
Une fois le déploiement terminé, vous voyez apparaître dans votre merge request l’url de votre webapp temporaire:
Vous pouvez vérifier que votre application tourne:
Côté console d’administration Clever Cloud vous pouvez modifier les paramètres d’exécution:
Une fois que tout vous semble bon, vous pouvez lancer le job de destruction de la VM:
Puis merger sur master et déclencher un déploiement en production (vous notez que le pipeline est différent, il n’y a aucune étape manuelle):
C’est plus long à décrire qu’à utiliser, mais c’est très pratique 😉.
Suite au prochain épisode 👋