GitHub Actions gjør det enkelt å lage egendefinerte arbeidsflyter for å gjøre utviklingshverdagen enklere. En arbeidsflyt kan i teorien være hva som helst ettersom alt er event-drevet, og ved hjelp av en YAML-fil definerer du enkelt et sett med commands du vil kjøre når en spesifikk event har inntruffet. I denne artikkelen ser vi på hvordan vi kan legge til en CI/CD-pipeline direkte i et GitHub-repository.
For å gjennomføre alle stegene i denne artikkelen forventes det at du allerede har et GitHub-repository og en Azure-konto, i tillegg til å ha installert .NET 5 og Azure-CLI.
.NET 5 app
Vi begynner med å lage et lite Web-API. Kjør følgende kommandoer fra din foretrukne terminal. Kommandoene lager en solution-fil, legger til et web api prosjekt, og kjører applikasjonen.
$ dotnet new sln$ dotnet new webapi -o <navn>$ dotnet sln add <navn>$ cd <navn>$ dotnet run
Jeg har brukt navnet MyAzureSampleApi. Etter å ha kjørt kommandoene kan du se APIet på https://localhost:5001/swagger.
For å se Swagger i Azure gå inn i Startup.cs og gjør Swagger tilgjengelig i alle miljø ved å fjerne IsDevelopment sjekken hvor Swagger registreres.
Azure App Service
For å opprette en "App Service"-instans i Azure gjør vi følgende fra en terminal:
Log in på din Azure-konto:
$ az login
List alle tilgjengelig Azure lokasjoner:
$ az account list-locations -o table
Opprett en Resource Group. Vi bruker lokasjonen "norwayeast" i dette tilfellet og oppretter en Resource Group med navnet "AzureSamplesResourceGroup".
Continous deployment til Azure App Service med Github Actions! | Progit
$ az group create --name AzureSamplesResourceGroup --location norwayeast
For å slippe å skrive inn Resource Group parameteren i de resterende kommandoene kan man gjøre følgende:
$ az configure --defaults group=AzureSamplesResourceGroup location=norwayeast
Alle applikasjoner i Azure trenger en App Service Plan, og her oppretter vi en som er gratis:
$ az appservice plan create --name AzureSamplesPlan --sku FREE
Nå kan vi opprette selve "App Service"-instansen. Her har vi spesifisert at den skal hete "MyAzureSampleApi" og kjøre på planen "AzureSamplesPlan" som vi opprettet i forrige steg. Videre har vi spesifisert runtime til .NET 5. For å se en liste av tilgjengelige runtimes kan man også kjøre følgende kommando:
$ az webapp list-runtimes$ az webapp create --name MyAzureSampleApi --plan AzureSamplesPlan --runtime "DOTNET|5.0"
Til slutt setter vi opp en Service Principal som har tilgang til å deploye til vår App Service. En Service Principal er en Active Directory Identity som brukes i automasjonscenarioer, som f.eks GitHub Actions.
$ az ad sp create-for-rbac --name "<appservice-name>" --role contributor --scopes /subscriptions/{sub-id}/resourceGroups/{resource-group} --sdk-auth
Output av kommandoen ovenfor legges inn i GitHub Secrets under nøkkelen AZURE_CREDENTIALS og brukes i YAML-filen vi setter opp senere.
Et alternativ til å opprette en Service Principal er å hente ut hele Publishing Profilen som ligger i Azure og legge den inn i GitHub Secrets isteden.
GitHub Actions
For å få en starter-template for ditt GitHub-repository kan man navigere til Actions. Her vil GitHub foreslå forskjellige templates basert på ditt repository. Disse templatene ligger selvfølgelig også tilgjengelig i et eget GitHub-repository, actions/starter-workflows. Eksempelet vi bruker i denne artikkelen er basert på .NET templaten:
name:Buildanddeploya.NET5apptoAzureAppServiceon: [push]
env:AZURE_WEBAPP_NAME:'MyAzureSampleApi'AZURE_WEBAPP_PACKAGE_PATH:'.'DOTNET_VERSION:'5.0.x'jobs:build:runs-on:windows-lateststeps:# Check out the repository-uses:actions/checkout@v2-uses:azure/login@v1with:creds:${{secrets.AZURE_CREDENTIALS}}# Setup .NET SDK-name:Setup.NETuses:actions/setup-dotnet@v1with:dotnet-version:${{env.DOTNET_VERSION}}# Run dotnet build and publish-name:dotnetrestore,build,andpublishrun:|
dotnet restore
dotnet build --configuration Release
dotnet publish -c Release -o '$/myapp'
# Deploy to Azure Web apps -name:RunAzurewebappdeployactionusingazurecredentialsuses:azure/webapps-deploy@v2with:app-name:${{env.AZURE_WEBAPP_NAME}}package:'$/myapp'-name:logoutrun:|
az logout
La oss gå igjennom de forskjellige stegene.
Først gir vi prosessen et navn og under on bestemmer vi hva triggeren er. I dette tilfellet starter vi byggprosessen på alle commits som blir pushet til repositoryet, uavhengig av hvilken branch du er på. Her kan man også f.eks konfigurere det slik at kun push til master skal trigge bygg.
env spesifiserer miljøvariabler som er tilgjengelige til alle stegene som kommer senere i workflowen. Her kan man også sette opp variabelbytter til f.eks appsettings.json om man ønsker det.
I jobs steget definerer vi selve byggprosessen. Hver workflow kan bestå av en eller flere jobs. I tillegg har hver job et eller flere steps. Under steps sjekker vi først ut koden og logger inn i Azure ved å bruke secreten vi la inn i GitHub tidligere. Deretter spesifiserer vi hvilken .NET version appen skal kjøre på før vi kaller på de vanlige dotnet kommandoene for restore, build og publish.
Til slutt deployer vi artifakten fra forrige steg til Azure.
For mer info, sjekk ut dokumentasjonen til Github Actions her.
En av fordelene ved å bruke GitHub Actions er at det finnes et hav av av Actions man kan benytte seg av på GitHub sitt marketplace. I dette tilfellet har jeg, litt tilfeldig, prøvd simple-slack-notfiy. For å poste til Slack kreves det i tillegg at du har opprettet og installert din egen Slack App på et workspace. For å lære hvordan du lager din egen Slack App finner du en fin oversikt i Slack sin offisielle dokumentasjon. I dette tilfellet har jeg brukt en eksisterende app, derav det ikke helt passende app-navnet.
Det eneste som kreves for å poste til Slack når du har gjort dette er å kopiere ut noe Slack kaller en incoming webhook url. Simple-slack-notify forventer å kunne lese denne fra en miljøvariabel under navnet SLACK_WEBHOOK_URL. I vårt tilfelle legger vi den inn som en secret vi refererer i vår action script.
Helt til slutt legger vi til et nytt step som spesifiserer hvilken Action vi bruker, i tillegg til hvordan meldingene skal se ut på Slack.
I denne artikkelen har vi lært hvordan vi kan bruke GitHub Actions til å publisere en applikasjon til Azure. I tillegg har vi sitt på mulighetene GitHub Actions Marketplace gir oss til å bygge på CI/CD pipelinen vår.
Endre Skogen
