Intro En général, quand on découvre une techno, on fonce direct en dev local et on s’amuse. C’est ce que j’ai fait aussi, mais j’ai pas tardé à mettre en prod. Car par expérience,  mieux vaut avoir les problèmes au début, tant que le projet est pas trop gros ou trop compliqué.  Donc l’idée de ce billet, c’est voir comment on pourrait monter une chaine CI/CD (continious intergration/ continuious deployement) sur un projet blazor de base.  Projet de base Blazor Avec Visual Studio 2022 Community, on créer un projet Blazor WASM, avec Hebergement Asp.net core et PWA : Pour ma part je l’ai nommé BlazorDemo.  Je me suis permis de modifier qu’une seule ligne, dans program.cs du projet server. Je spécifie juste un port pour ma prod. Voir artile https://reactor.fr/net-core-sous-linux-nginx-80-http-443-https-firewall/ Azure DevOps Pipelines Azure Devops, c’est GitHub, Maven, Jenkins et j’en passe tout ça dans une appli web.  Ca nous permet de faire du CI/CD depuis nos propres repos (qu’ils soient sur BitBucket, Azure devops, GitHub, ou autre…) L’idée est de partir sur deux branches git, une master et une develop.  La master sera considéré comme la Prod. La develop comme la branche de travail.  A chaque fois que la branche master recevra un commit, on lancera une "pipeline" qui fera plusieurs actions, comme builder, lancer des tests et deployer.   A l’avenir, la branche master ne pourra plus recevoir de commit directement, ceci sera bloqué par defaut. Le seul moyen sera de faire une Pull Request depuis la branche develop vers la branche master. Ceci afin de mettre en place de bonne pratique de développement et de gestion de code source.  Bien sûr on pourrait pousser le concept plus loin, en pratiquant du Git Flow par exemple. Mais restons simple pour bien comprendre les mécanismes d’AzureDevOps 1ere pipeline Commençons par créer notre première pipeline. Menu Pipeline Cliquez sur New Pipeline Comme je le disais tout à l’heure, notre code source peut se situer sur différent repos, choisissez le votre : On choisit ensuite son repos, dans mon cas ceci :  Ensuite il faut choisir un modèle de script YAML. Alors ici, c’est pas clair je trouve. J’ai choisis "Asp.net Core" qui n’est pas présenté comme premier choix. Ce qui pourrait m’induire en erreur. Enfin de toute manière, c’est qu’un modèle, qu’on peut modifier par la suite. Voici le résultat : En cliquant sur Save and Run, puis valider l’écran suivant par defaut, vous allez ajouter un fichier "azure-pipelines.yml" a la racine de votre repo, sur la branche master. S’en suit un run automatique, qui au bout de qq seconde va échouer : En cliquant dessus pour voir le détail : Puis sur Job et sur l’élément en rouge : On a le détail du pourquoi le job a échoué. On a le détail du pourquoi le job a échoué. Ca nous dit que l’on a pas spécifier de projet à compiler… et c’est vrai MSBUILD : error MSB1003: Specify a project or solution file. The current working directory does not contain a project or solution file. Correctif de la 1ere pipeline Vous pouvez corriger directement depuis la plateforme azure devops pour bien le faire depuis votre editeur préféré et jouer qq commande git. Pour ma part je préfère cette derniere.  Je récupère donc via un git pull ma branche master sur mon visual studio code et je modifie le fichier azure-pipelines.yml avec cette ligne script: dotnet build –configuration $(buildConfiguration) src/BlazorDemo/BlazorDemo/Server/BlazorDemo.Server.csproj Le path ici peut différer selon votre répertoire repos. (moi j’ai mis tout ca dans un folder src, qui contient un répertoire  blazordemo qui contient un répertoire "solution" blazordemo. Quand votre modification est faites, il faut alors mettre a jour le repo distant avec un commit.  Rappelons que lorsque la branche master subit un nouveau commit, ca lance automatiquement cette pipeline. Et normalement vous obtenez un build vert :  Et voila, on a fait notre première pipelines qui fait qq chose de très basique pour le moment, builder !