Cet article est le second d'une série sur Github Actions et la mise en place d'une chaîne CI/CD.

Aujourd'hui, nous verrons comment créer un pipeline de déploiement d'applications sur Azure PaaS.

Vous pourrez même afficher un petit badge ;)

Préparation

Tout d'abord, il faut avoir Github Actions activé. Oui, je l'ai déjà dit lorsque l'on a mis en place l'intégration continue mais bon... Encore une fois, allez faire votre demande d'accès rapidement ou attendez le 13 novembre pour la disponibilité générale.

Il vous faudra également avoir packagé votre application et créé un artifact. Pour cela je vous invite à revenir à mon article précédent, et notamment la section Package & Artifacts.

Vous devriez voir votre artifact dans la partie en haut à droite de vos logs de workflow :

 

Azure Web App

Pour déployer notre application dans une Web App Azure, il nous faut ... ? Allez je vous laisse encore quelques sencondes... une Web App?! Ouiiii! Bravo !

 

Provisionnement

Je ne vous montrerai pas ici comment provisionner une Web App mais je peux vous fournir un lien vers la documentation App Service.

Pour les allergiques du clic ou afficionados de l'automatisation poussée, je vous renvoie vers le blog post de mon collègue Wilfried qui a déjà expliqué comment déployer une infra via ARM depuis Github Actions.

Bref, dans tous les cas, on partira ici du principe que votre Web App est provisionnée, et que votre artifact s'appelle webapp.

 

Publishing Profile

Pour déployer votre Web App, vous aurez besoin du profil de déploiement. Comme son nom l'indique, il contient les informations nécessaires pour le déploiement, telles que l'url, les identifiants de connexion, etc.

Ouvrez le portail Azure et naviguez jusqu'à votre Web App.

Dans la barre de commandes en haut, cliquez sur "Get publish profile".

Get publish profile

Une fois le fichier téléchargé, ouvrez-le avec un éditeur de texte et copiez le contenu du fichier XML :

<publishData><publishProfile profileName="actionsSampleApp - Web Deploy" publishMethod="MSDeploy" ...

 

Retournons maintenant dans notre repository Github.

Ouvrez le menu Settings, puis dans le menu de gauche, ouvrez le panneau Secrets.

github-secrets.png

Cliquez ensuite sur Add a new secret et collez le contenu de votre publish profile.

Vous devriez donc avoir un nouveau secret dans votre repo :

github-secrets-publish-profile.png

Passons ensuite au workflow et aux étapes de déploiement.

 

Workflow de déploiement

Nous reprendrons ici le fichier workflow que nous avions commencé dans l'article sur l'intégration continue.

/.github/workflows/{workflow_name}.yml

 

Dans ce fichier, nous allons ajouter des étapes de déploiement, en commençant par déclarer un job que nous appelerons "deploy" et qui nécessite l'éxécution du job "build" au préalable.

nameASP.NET Core CI

on: [push]

jobs:
  build:
...
 
  deploy:

    needsbuild
    runs-onwindows-latest

 

La première étape consiste à récupérer le package de notre application, c'est-à-dire l'artifact. Pour cela, nous utiliserons l'action download-artifact en lui précisant le nom de l'artifact webapp.

    steps:
    - nameDownload Artifacts
      usesactions/download-artifact@master
      with:
        namewebapp

 

Nous voici enfin à l'étape tant attendue de déploiement.

Nous utiliserons ici l'action appservice-actions/webapp. Il faudra préciser à l'action le nom de la Web App, le nom du package, ainsi que le nom du Secret au format :

 secrets.{secret_name}.

    steps:
    - ...

    - nameDeploy to Azure App Service
      usesazure/appservice-actions/webapp@master
      with:
        app-nameactionsSampleApp
        packagewebapp
        publish-profile${{ secrets.webappPublishProfile }}

 

 

Il ne vous restera alors qu'à démarrer manuellement votre pipeline ou à attendre votre prochain commit sur master, via une PR évidemment ;)

github-actions-deploy-success.png

Conclusion

Dans cet article, nous avons découvert comment utiliser Github Actions 2.0 pour mettre en place un pipeline de déploiement continu en quelques minutes.

Dans un prochain article, nous découvrirons des fonctionnalités avancées de Github Actions pour Azure.

A bientôt !

Il y a quelques jours j'ai reçu le Saint-Graal: l'activation de la fonctionnalité Actions de Github.

Il s'agit là de pouvoir gérer ses pipelines de Continuous Delivery directement depuis Github.

Après avoir pu jouer un peu, je vais pouvoir vous faire un petit état des lieux sur Github Actions et notamment l'utilisation pour construire un pipeline d'intégration continue pour vos applications dotnet core.

Vous pourrez même afficher un petit badge ;)

Préparation

Tout d'abord, il faut avoir Github Actions activé. Oui ça paraît con, mais je préfère le dire avant qu'on me dise "Ouiiin ça marche pas !". Pour ceux qui ne l'auraient pas encore et se tiennent prêts à me dire "Oh tu te la pètes avec ton accès à Github Actions", sachez qu'il semble y avoir des vagues de validation en masse ces derniers jours. Alors allez faire votre demande d'accès rapidement ou attendez le 13 novembre pour la disponibilité générale.

Ensuite, il vous faut un repository avec le code d'une application dotnet core. Si vous n'en avez pas, vous pouvez toujours forker le repository suivant : https://github.com/MicrosoftDocs/pipelines-dotnet-core. C'est celui que j'utiliserai dans ma démo.

Workflow template

Passons aux choses sérieuses.

Dans votre repository, cliquez sur Actions.

github-actions.png

Dans la fenêtre Actions, vous pouvez choisir de partir sur un workflow complètement vide ou de choisir un template correspondant à votre projet.

Pour cet exemple, nous choisirons le template ASP.NET Core. Vous pouvez aussi partir d'un template vide et tout retaper mais bon...

aspnetcore-github-workflow-template.png

Une fois votre template choisi, Github crée pour vous un fichier au format YAML. C'est là que la magie opère.

Si vous avez déja touché au YAML avec Azure DevOps ou un autre gestionnaire de pipeline, alors vous ne serez pas dépaysés, même si des spécifités existent entre les éditeurs: "Just another flavor of YAML" ;) Pour les autres et ceux qui voudraient connaître les fonctionnalités disponibles dans le YAML à la sauce Github Actions, vous pouvez vous rendre sur la documentation associée.

Build

Regardons un peu notre fichier YAML de workflow.

github-actions-aspnetcore-template.png

 

Il faut tout d'abord définir le "trigger" ou "déclencheur" du workflow. A chaque push sur le repository, le workflow sera déclenché.

on: [push]

 

Ok, maintenant on s'attaque au build puisque l'on souhaite réaliser notre intégration continue.

jobs:
build:

 

On fait du .NET Core donc on peut compiler sur une distrbution Linux et on ne va pas se priver.

runs-on: ubuntu-latest

 

On utilise ici une action packagée et proposée par Github pour installer la CLI dotnet sur l'agent en spécifiant la version.

uses: actions/setup-dotnet@v1
with:
dotnet-version: 2.2.108

 

Enfin, on utilise la CLI dotnet pour lancer la commande de build de notre projet. Nous ne spécifions pas le dossier dans cet exemple mais, selon votre arborescence de repository, il faudra peut-être spécifier le ou les fichiers .csproj à compiler.

- name: Build with dotnet
run: dotnet build --configuration Release

 

Logs

Une fois le fichier sauvé et inclus dans le répository Github, l'action sera déclenchée et vous pourrez suivre le déroulement de celui-ci.

github-actions-build-success.png

Par défaut un email est envoyé en cas d'échec du workflow.

Vous pouvez également ajouter un petit badge dans le déscriptif de votre repository ou tout autre endroit pertinent en utilisant le format d'url suivant :

https://github.com/{github_id}/{repository}/workflows/{workflow_name}/badge.svg

Cool, on a créé un workflow qui, à chaque push sur master, démarre un build sur notre projet et nous informe en cas d'erreur. Essayons d'aller un peu plus loin.

Tests

"Hey Michaël, tu nous saoules avec tes tests sur tous tes projets et tu crois qu'on va te laisser t'en sortir comme ça ?"

Vous avez raison, notre application compile, c'est bien mais pas suffisant pour une intégration continue. Voyons donc comment effectuer quelques tests unitaires.

La CLI dotnet comporte une commande test qu'il ne nous reste qu'à ajouter comme step de notre fichier de workflow :

- name: Test with dotnet
run: dotnet test --configuration Release

Là encore, je ne précise pas les projets de tests car mon arborescence me le permet, mais libre à vous de les spécifier.

Package & Artifacts

Une fois notre Build effectuée et les tests passés avec succès, dans une optique de pipeline d'intégration continue (voire de déploiement continu), il nous faut générer un package de notre application.

Pour cela, rien de plus simple, il nous suffit de rajouter quelques steps.

Tout d'abord, nous allons packager notre application :

- name: Package with dotnet
run: dotnet publish --configuration Release

Et enfin, nous allons publier le résultat dans un artifact.

- name: Publish artifact
uses: actions/upload-artifact@master
with:
name: webapp
path: bin/Release/netcoreapp2.2/publish

Nous utilisons ici l'action packagée et proposée par Github actions/upload-artifact. Cette action nécessite de définir un nom ainsi que le répertoire à inclure dans cet artifact.

Une fois ces actions ajoutées et ajustées à vos besoins, vous devriez voir apparaître un nouveau bouton en haut à droite de vos logs de worflow.

github-actions-artifact.png

 

Conclusion

Dans cet article, nous avons découvert Github Actions 2.0. Cela pourra s'avérer désuet pour ceux qui connaissaient déjà Actions ou Azure DevOps, mais il me semble que l'outil soit peu connu et notamment dans l'écosystème .NET. De plus, la mise en place d'une intégration continue en quelques minutes, de manière gratuite et sans sortir de Github me paraît vraiment intéressante.

Dans un prochain article, nous découvrirons Github Actions for Azure.

A bientôt !