Azure DevOps helpt je de werelden van Development en Operations dicht bij elkaar te brengen. Het doel is om zo snel mogelijk en vaak mogelijk jouw oplossing te releasen en daarbij de kwaliteit van de oplossing te waarborgen. Leer in deze blog hoe je Azure DevOps kunt inzetten om jouw Office 365 maatwerk oplossingen zo snel mogelijk en vaak mogelijk te releasen.
Microsoft Team Foundation Server
De voorgang van DevOps is Team Foundation Server. Teams Foundation Server zag ik als een soort verijdelde tool, waar je je code in opslaat. Natuurlijk waren er toen al tools en middelen voor handen binnen Team Foundation Server voor het snel ontwikkelen en uitbrengen van jouw software. Azure DevOps gaat daar nog een stapje verder in.
Waar staat DevOps voor in Azure DevOps?
DevOps bestaat uit 2 woorden Development en Operations. Deze term gebruiken we om de praktijk van softwareontwikkeling (Development) en softwareoperaties (Operations) bij elkaar te brengen. DevOps brengt alle onderdelen van automatiseren bij elkaar. Denk bijvoorbeeld aan het bouwen van software , het testen van software en ook integratie, infrastructuur, releasen en deployment, Het gaat dus veel verder dan alleen maar je code ergens opslaan. Het doel van DevOps is om software zo snel en vaak mogelijk te releasen en de kwaliteit daarbij te waarborgen.
Wat nu zo mooi is, is dat Azure DevOps hier een implementatie voor heeft om DevOps te bewerkstelligen. In deze blog behandelen we niet alles van Azure DevOps, maar we richten ons op een onderdeel: Azure Pipelines. Met Azure Piplelines build je geautomatiseerd Office 365 oplossingen.
Azure Pipelines
Azxure Pipelines is een cloud dienst waarbij je geautomatiseerd code build, test en jouw oplossing beschikbaar maakt voor anderen. Het combineert continue inegratie (CI) en constante opleveren (CD), waardoor je constant je code test en build op weg naar een oplevering.
Azure Pipeline voor Office 365
Aan de hand van een voorbeeld laat ik zien hoe Azure Pipeling integreert met Office 365. We gaan een Management Systeem uitrollen naar een staging omgeving, steeds als er een nieuwe code is gecomit. Het systeem gebruikt Office 365 WebParts. De code van WebParts staat in een Azure DevOps GIT repository en via de pipeline wordt deze gebuild , getest en uitgerold naar de staging omgeving.
Aan de slag met Azure DevOps
Ga naar Azure DevOps en ga naar pipelines. Vervolgens ga je naar build. Hier kun je een nieuwe build pipeline aanmaken. Klik op new en kies hier voor new build pipeline om een nieuwe pipeline aan te maken.
Maak een YAML
In het vervolgscherm heb je 2 opties. Je gebruikt de klassieke editor om je pipeline te maken of je gebruik YAML om je pipeline te definiëren. YAML staat voor Yet Another Markup Language, Het is een taal die configuraties beschrijft. We gaan in dit voorbeeld uit van de YAML variant. Maar voor dat zover is, kies je eerst waar je code vandaan komt. We maken gebruik van Azure Repos GIT. Kies deze en kies vervolgens de repository waar jouw Office 365 webparts staan.
Om te starten selecteer je uit een gefineerde pipeline. Voor Office 365 kies je voor Node. Je krijgt nu een YAML die er ongeveer zo uit ziet.
# Node.js
# Build a general Node.js project with npm.
# Add steps that analyze code, save build artifacts, deploy, and more:
# https://docs.microsoft.com/azure/devops/pipelines/languages/javascript
trigger:
– master
pool:
name: Hosted Windows 2019 with VS2019
demands: node.js
steps:
– task: NodeTool@0
inputs:
versionSpec: ‘8.x’
displayName: ‘Install Node.js’
– task: Npm@1
displayName: ‘npm install’
inputs:
workingDir: solution
verbose: false
Onderdelen Azure DevOP
Wat betekenen nu de verschillende onderdelen?
Trigger
Trigger geeft aan wanneer de build pipeline wordt geactiveerd. In dit geval wordt de pipeline geactiveerd wanneer er een nieuwe code wordt gecomit naar de master branch.
Pool
De pool geeft aan wanneer de build pipeline activeert. In afbeelding 3 op een Windows 2019 machine met Visual Studio 2019. Een vereiste is dat hier node.js op staat.
Steps
Steps geeft de stappen weer om alles op te bouwen. Je kunt zien in afbeelding 3 dat de hoogste versie van Nodels 8 wordt opgehaald. Vervolgens worden alle npm pakketjes, die horen bij Office 365 SPFx webparts, geïnstalleerd.
Nog meer YAML
YAML willen we nog meer gaan uitbreiden met een paar extra taken. Voor Office 365 webparts voeren we de volgende extra taken uit.
- Een Unit Tests om er zeker van te zijn dat er geen nieuwe bugs geïntroduceerd zijn als gevolg van de nieuwe comit
- Een gulp taak die alle code bundelt en klaar maakt voor release
- Een gulp taak die van het geheel een SPFx pakketje maakt die klaar is voor uitrol
- Via Powershell online het pakketje uitrollen op de staging omgeving (een SharePoint Site) en de PnP Provisioning template bijwerken / uitrollen op staging
Om dit te doen breiden we YAML uit met de volgende punten:
– task: Npm@1
displayName: ‘npm test’
inputs:
verbose: false
Met deze taak voeren we de unit tests uit. Het project maakt gebruik van Jest; een test framework voor javascript.
– task: PublishTestResults@2
inputs:
testResultsFormat: ‘JUnit’
testResultsFiles: ‘**/JUnit.xml’
Met bovenstaande taak publiceren we de testresultaten.
– task: Gulp@0
displayName: ‘gulp bundle’
inputs:
gulpFile: solution/gulpfile.js
targets: bundle
arguments: ‘–ship’
Met deze taak wordt de gulptaak uitgevoerd om de bestanden te bundelen en klaar te maken voor release. Je geeft bij de gulpfile input de locatie op van de gulpfile. Bij de targets input geef je het build commando op dat je wilt uitvoeren. Verder geef je de argumenten mee aan de gulp via de arguments input.
– task: Gulp@0
displayName: ‘gulp package-solution’
inputs:
gulpFile: solution/gulpfile.js
targets: ‘package-solution’
arguments: ‘–ship’
Op dezelfde manier geef je de gulptaak op om een SPFx pakketje te maken die klaar is voor gebruik.
– powershell: |
Install-PackageProvider -Name NuGet -Force -Scope “CurrentUser”
Install-Module SharePointPnPPowerShellOnline -Scope “CurrentUser” -Verbose -Force
displayName: ‘PowerShell Script’
Voordat je met Powershell aan de slag gaat moet je ervoor zorgen dat deze op de gehoste omgeving beschikbaar is. Bovenstaand commando zorgt ervoor dat de SharePointPnPPowershellOnline cmdlet beschikbaar is op de omgeving waar vanuit de pipeline wordt uitgevoerd.
– task: PowerShell@2
displayName: ‘PowerShell Script’
inputs:
targetType: filePath
filePath: ‘./provisioning/enroll_staging.ps1’
Als laatste voeren we een Powershell script uit. Het is een script dat gebruik maakt van het SharePointPnPPowershellOnline CMDlet. Met filepath geef je aan waar het script in je GIT repository staat. Aan het script kun je nog een hele blog besteden. Om je hierbij op weg te helpen licht ik 2 zaken toe die het script uitvoert:
- Het voert een update uit of voegt Office 365 Webparts toe die gebuild zijn..
- Het voert een update uit van het PnP Provisioning template
Dat komt er dan zo uit te zien:
Write-Host “Provisioning solution” -ForegroundColor Cyan
$existingApp = Get-PnPApp -Identity “ms-app” -ErrorAction SilentlyContinue
if ($existingApp -ne $null) {
Remove-PnPApp -Identity $existingApp
}
Set-PnPTraceLog -On -Level:Debug;
Apply-PnPProvisioningTemplate -Path “$PSScriptRoot\ms.xml” -Connection $connection
Write-Host “Update ms webpparts” -ForegroundColor Cyan
Update-AppIfPresent -AppName “ms-app” -Connection $connection
Voor het opslaan en testen van je YAML klik je op Save and Run en geef je het een naam.
Alle opgegeven taken worden stap voor stap uitgevoerd. Dit resulteert in een geteste uitrol van de laatste versie van ons Management Systeem, die klaar is voor release. Dit alles door alleen een comit te doen van de laatste code!
Tot slot!
Door de build pipeline die we hebben gemaakt wordt een complete Office 365 oplossing op staging geupdate. Zo zie je dat we met Azure DevOps constant Office 365 oplossingen kunnen opleveren en integreren.