Dans un précédent article (http://www.arolla.fr/blog/2019/08/tag-ressources-azure-createur/) nous avons vu comment taguer les ressources Azure avec leur créateur.
Nous avons ensuite vu comment mettre en place une stratégie de tests (http://www.arolla.fr/blog/2019/08/tester-son-infrastructure-azure-avec-pester/).
Nous somme maintenant arrivée à la dernière étape de cette série d’articles
Nous allons mettre en place une intégration continue pour le produit de tag.
La démarche
Avant de nous intéresser aux outils et à la mise en place, un petit mot sur la démarche.
Dans notre intégration continue, nous allons mettre en place deux builds :
- Le premier ne lancera uniquement les tests unitaires. Comme nous l’avons vu dans l’article sur les tests, ceux-ci sont gratuits et rapides à s’exécuter. Nous pourrons donc les lancer très fréquemment, c’est a dire a chaque commit sur une branche et à chaque Pull Request.
- Le second lancera l’intégralité des tests (unitaire, déploiment et acceptance). Il sera plus long à s’exécuter et consommera des ressources Azure. Nous allons donc le lancer de manière planifiée une fois par jour
Il ne s’agit pas ici d’une règle absolue à suivre, mais plutôt d’une exemple de stratégie permettant à une équipe de développement de pouvoir produire sans attendre la fin d’un build pendant des heures, et de garantir que le produit est toujours fonctionnel.
Azure devops
Nous allons utiliser Azure devops afin de mettre en place les builds.
Je vais ici supposer que vous avez déjà une organisation dans Azure devops que vous pouvez utiliser.
La première étape est de créer un projet