IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

DevOps avec Azure - Partie 6 : apprendre à mettre en place une stratégie de CI & CD pour l'infrastructure et le Code - Approche 2
Par Hinault Romaric

Le , par Hinault Romaric

0PARTAGES

Ce billet est la sixième partie de ma série consacrée à DevOps avec la plateforme Cloud Microsoft Azure.


DevOps sur Microsoft Azure – Partie 1 : Introduction à DevOps

DevOps avec Azure – partie 2 : Infrastructure as Code (IaC) avec Azure ARM

DevOps avec Azure – Partie 3 : Création et déploiement des ressources avec Visual Studio et ARM Template

DevOPS avec Azure – Partie 4 : ARM Template CI & CD avec VSTS

DevOps avec Azure – Partie 5 : stratégie de CI & CD pour l’infrastructure et le Code, 1re approche

Dans la première approche que j’ai présentée dans mon précédent billet, nous avons utilisé le même pipeline pour exécuter les tâches de build et de déploiement de l’application et l’infrastructure. Cette approche est celle que je prône. Mais, vu que les modifications de l’infrastructure peuvent être moins fréquentes que celles du code, que vous pouvez utiliser un "versioning" différent pour le code et l’infrastructure, ou pour toute autre raison, vous pouvez décider d’utiliser des pipelines différents pour l’infrastructure et le code.

Nous verrons comment procéder dans ce billet de blog.

Création de la Build Definition

Ouvrez VSTS dans votre navigateur allez dans Release, puis procédez à la création d’une nouvelle Build Definition en utilisant le template ASP.NET Core :



Ce template dispose de toutes les tâches nécessaires à la génération et la publication de l’application : restauration des packages NuGet, génération du projet, exécution des tests unitaires, publication de l’application et transfert dans le dossier de destination de l’artefact.



Toutes les tâches ont été configurées comme il se doit. Aucune modification n’est nécessaire. Il ne vous reste plus qu’à activer l’intégration continue dans l’onglet Triggers, puis enregistrer vos modifications et mettre en file d’attente une nouvelle Build, pour vous assurer que tout fonctionne correctement.

Création de la Release Definition.

Passons maintenant à l’étape de création de la Release Definition pour le déploiement de l’application dans l’infrastructure Azure App Service que nous avons créé dans le billet précédent.

Allez dans la section Releases, puis ajoutez une nouvelle Release Definition en utilisant le template Azure App Service Deployment.



Vous allez nommer l’environnement Dev. Ensuite, vous devez ajouter l’Artefact en utilisant « AzResource-ASP.NET Core-CI » comme Source. N’oubliez pas d’activer le déploiement continu.

Il ne vous reste plus qu’à configurer la tâche de déploiement. Cela se fait dans via l’onglet Tasks. Vous aurez besoin de renseigner votre suscription Azure et le nom de votre Azure App Service :



Enregistrez et mettez en file d’attente une nouvelle Release pour vous assurer que tout fonctionne correctement.

Une fois l’application déployée, ouvrez le portail Azure, sélectionnez votre App Service et accédez à votre application via l’adresse URL obtenue à partir du portail Azure :



Stratégie de CI & CD pour l’infrastructure et le Code

Si vous apportez une modification au code, vous allez constater suite à votre commit que les deux builds vont démarrer. En mettant en place des Builds Definition différentes pour le code et l’infrastructure, nous voulions justement que les tâches de build et déploiement de l’infrastructure ne s’exécutent que lorsque la modification concerne le code de l’infrastructure et vice-versa.

Pour remédier à cela, vous allez éditer chaque Build Definition et ajouter un filtre pour ternir uniquement compte des modifications effectuées sur les fichiers dans le dossier de chaque projet :



C’est tout pour aujourd’hui. Dans le prochain billet, nous verrons les différents outils qui sont offerts à partir du portail Azure pour configurer rapidement un pipeline d’intégration et livraison continues de son application.

Une erreur dans cette actualité ? Signalez-nous-la !