Vous avez peut être entendu parler de l'arrivée d'une nouvelle fonctionnalité appelée Review Apps sur Azure DevOps couplé avecKubernetes (en lisant l'article Kubernetes - Conteneurs : quelle utilité pour un développeur (dotnetcore) ? par exemple) et souhaitez avoir un exemple un peu plus concret ?

Et bien vous êtes arrivé sur le bon article de blog, dans lequel nous allons voir un exemple de mise en place de cette fonctionnalité encore en Public Preview.

Le workflow de Review Apps

Dans les grandes lignes, la seule chose à effectuer sera de créer une nouvelle Azure Pipeline utilisant le template Deploy to Kubernetes, et d'activer la case à cocher Enable Review Apps workflow for Pull Request. Et voilà, c'est tout !

Azure DevOps va ensuite vérifier si la Build a été déclenchée par une Pull Request, et si oui, va créer un nouveau namespace Kubernetes pour déployer à l'intérieur.

Mais assez d'explications, voyons pas à pas les étapes à suivre pour mettre en place les Review Apps avec une simple application aspnetcore.

Les prérequis pour utiliser Review Apps

En plus de notre application, nous aurons besoin d'un fichier Dockerfile afin de générer une image Docker à déployer.

Note : pour ajouter le support de Docker sur un projet existant, vous pouvez utiliser la fonctionnalité intégrée de Visual Studio Add Docker Support comme décrit dans la documentation officielle.

Nous aurons également besoin d'un cluster Kubernetes tel que fourni par Azure Kubernetes Service, ainsi que d'un container registry tel qu' Azure Container Registry.

Note : La documentation officielle de Microsoft détaille la création d'un Azure Kubernetes Service ainsi que d'un Azure Container Registry depuis le portail Azure.

Création d'une pipeline Azure DevOps pour déployer sur Kubernetes et activer les Review Apps

Pour démarrer l'utilisation des Review Apps, le plus simple est de créer une nouvelle Azure Pipeline et de sélectionner le template Deploy to Azure Kubernetes Service.

Après avoir sélectionné le cluster Kubernetes, nous avons juste besoin de configurer quelques informations telles que le Namespace Kubernetes cible, le Container Registry où trouver notre image Docker, le port (80 ou 443) à utiliser pour accéder à notre service déployé, et surtout, il ne faut pas oublier de cocher la case Enable Review App flow for Pull Requests.

3 fichiers seront ajoutés :

• Un fichier azure-pipelines.yml qui décrit notre pipeline (Build, Deploy et Deploy Pull Request),
• Un fichier manifests/deployment.yml qui décrit l'application à déployer sur Kubernetes (le nom de l'image docker à utiliser, et le port à utiliser pour y accéder),
• Un fichier manifests/service.yml pour décrire notre service Kubernetes, et surtout comment y accéder (par défaut en utilisant le LoadBalancer qui permet d'obtenir une IP publique depuis Azure)

Si l'on regarde un peu plus en détail le contenu du fichier azure-pipelines.yaml, on distingue 3 étapes :

• Le stage deBuild qui va simplement builder notre image docker et la pousser sur le registry.
• Le job Deploy qui est exécuté par défaut, et permet de déployer sur le namespace Kubernetes configuré par défaut.
• Le job DeployPullRequest déclenché uniquement lorsque la branche source est une branche de Pull Request, et va créer un nouveau namespace Kubernetes pour déployer à l'intérieur.

Déclencher automatiquement la build pour chaque Pull Request via les Branch Policies

Rien de bien original ici, on utilisera la fonctionnalité de Branch Policies d'Azure DevOps pour déclencher notre build automatiquement lors de la création d'une Pull Request.

Plus d'informations sur les manipulations à effectuer sur la page de documentation officielle.

Fixer l'erreur "A valid name is less than 256 characters in length and does not contain the following characters"

Si vous tentez de créer une nouvelle Pull Request maintenant, il est possible que vous rencontriez un petit bug à cause du nom du namespace Kubernetes créé par défaut, se basant sur le nom de la branche source, et contenant des caractères invalides.

##[error]Resource name 'refs/heads/MY_PR_NAME' is not valid. A valid name is less than 256 characters in length and does not contain the following characters: ',', '"', '/', '\', '[', ']', ':', '|', '<', '>', '+', '=', ';', '?', and '*'.

J'ai préféré opter pour générer un nom de namespace composé du nom de la build, suffixé de l'id de la pull request, ce qui donne la ligne suivante à remplacer dans notre fichier azure-pipelines.yaml:

k8sNamespaceForPR: 'reviewappsdemo-$(System.PullRequest.PullRequestId)'

Un nouvel essai de Pull Request + Build devrait s'avérer cette fois-ci concluant. Félicitations !

Récupérer l'adresse publique pour tester le nouvel environnement créé par Review Apps

En se rendant dans la partie d'Azure Pipelines Environment, et en naviguant sur notre cluster Kubernetes, on va trouver le namespace généré par notre Pull Request :

Ensuite dans le menu Service de notre namespace, on devrait pouvoir y trouver son ip publique :

En essayant d'y accéder via un navigateur web , on devrait pouvoir visualiser les modifications effectuées sur notre Pull Request ! Plutôt pas mal n'est-ce pas ?

Fini les revues CSS à l'aveugle, plus de revues techniques sans vérifier le comportement fonctionnel, Review Apps est un super outil lorsque vous souhaitez améliorer la qualité de vos Pull Requests !

Review Apps : Et maintenant ?

Même si cette fonctionnalité est toujours en preview, le principe mis en oeuvre reste très simple et pourtant très puissant !

Quelques petits points supplémentaires que j'ai hâte de voir apparaître pour compléter ce scénario :

• Un déploiement Review Apps effectué via helm,
• L'ajout automatique de l'adresse publique de notre environnement dans les commentaires de la Pull Request,
• Un nettoyage automatique du namespace de la Pull Request lorsque le merge est effectué

Vous pouvez jeter un œil à mon projet Azure DevOps de démo

N'hésitez pas à réagir dans les commentaires ou sur Twitter @vivienfabing, et que le code soit avec vous !