L’idée est simple ; Partant
du principe qu’un environnement des tests automatisés n’est sollicité qu’au
moment d’un merge de code pour jouer les tests de non-régression (voire
d’autres types de tests en fonction des besoins de chaque équipe), nous allons tenter
de le créer uniquement pendant ces exécutions (directement depuis la pipe
d’intégration) et de le détruire une fois le travail terminé.

Cela réduit la consommation Cloud
à la seule durée des tests, on sera donc sur des ratio imbattables.

Imaginez une Feature Team
standard (4/5 peoples) qui gère une ou plusieurs applications aux architectures
non-complexes (Appli de gestion, Micros Service…), cette équipe merge son code
3 fois par jour et lance une batterie de tests automatisés à chaque
intégration, imaginons que chaque exécution des scénarios de tests dure 20min
> Notre solution va réduire la durée de vie des environnements de tests à (3
x 20min = 1h) contre 24 heures sur des environnements dédiés.

Le calcul est simple : Vous
allez diviser votre facture de conso sur vos environnements de tests par 24 et
cela fera sans doute des heureux !

Use Case

Pour les besoins de cet article,
nous allons opter pour un exemple d’API très simple, cela nous permettra de
nous concentrer sur le cœur du sujet à savoir, le provisionning éphémère de nos
environnements de test.

Partons sur l’exemple fourni par
défaut par Microsoft pour la création de tout nouveau projet API ; il
s’agit d’une API Météo assez simple incluant une seule route GET /weatherforecast
et qui retourne une réponse JSON indiquant la météo des 5 prochains jours.

Mise en œuvre

Bootstrappez le projet ASP.NET WebAPI