In mijn vorige blog heb ik iets geschreven over het inrichten van een Releasepipeline in Azure DevOps. Deze blog wil ik besteden om uit te leggen hoe je het mogelijk maakt om een applicatie geschikt te maken voor het CI/CD (Continious Integration en Continious Delivery) voor meerdere omgevingen. We starten hier met het maken builds voor de verschillende omgevingen en daarna met het deployen naar twee omgevingen.

Stap 1: Inloggen in Azure DevOps

Ga naar https://devops.azure.com en log in met je Azure Active Directory login en ga vervolgens naar het project waar je dit voor in wilt richten. In mijn voorbeeld is dit het bekende Contoso project van Microsoft.

Stap 2: Aanmaken van een nieuwe Build Pipeline

Kies in het linkermenu onder het item “Pipelines” voor “Builds”. Wanneer je nog geen pipeline gemaakt hebt krijg je een blauwe knop te zien voor het aanmaken van een nieuwe pipeline. Wanneer je al één of meerdere pipelines ingesteld hebt, dan zul je hier een lijstje zien van de gemaakte pipelines.

Kies bovenin voor de optie New en dan “New Build Pipeline”

Selecteer vervolgens in het volgende menu de mappen waar de bestanden staan die gebuild moeten worden. Nadat je op continu geklikt hebt kun je gebruik maken van een template. In mijn voorbeeld heb ik een ASP.NET applicatie en kies ik voor ASP.NET. In het volgende scherm gaan we een aantal instellingen doen voor het builden van meerdere versies van de source-code.

Stap 3: Build Pipeline instellen voor meerdere omgevingen

Onder het tabje “Tasks” moet je de volgende instellingen doorvoeren:

• Op Pipeline moet de Artifact Name ingesteld worden op: “$(BuildConfiguration)

• Bij Agent Job 1 onder “Execution plan moet Parallelism op Multi-configuration staan en de Multpliers op BuildConfiguration

• Onder de Task “Build solution” moet je bij de MSBuild Arguments de packagelocation aanpassen naar: /p:PackageLocation=”$(build.artifactstagingdirectory)\\$(BuildConfiguration)“
• Instelling voor Configuration moet ingesteld worden op: “$(BuildConfiguration)“

• Onder de Task “Publish Artifact” moet het Path to public ook ingesteld worden als het argument onder MSBuild, dus: $(build.artifactstagingdirectory)\$(BuildConfiguration)

Onder de tab Variables kun je het volgende instellen:

• Bij BuildConfiguration kun je nu meerdere Build-versies generen, in mijn voorbeeld is dit: Acceptance en Release

Als bovenstaande instellingen allemaal goed staan kun je de pipeline opslaan en een nieuwe build aanmaken.

Stap 4: Release Pipeline inrichten met meerdere omgevingen

Nadat de builds aangemaakt zijn kun je vanuit het scherm een nieuwe release aanmaken. Bekijk hiervoor mijn vorige blog. Pas de volgende gegevens aan om meerdere omgevingen beschikbaar te maken:

Volg de volgende stappen om achtereenvolgens een acceptatie- en productieversie vrij te geven:

• Maak een nieuwe stage aan met de naam Acceptance
• Kies voor de voor het publiceren van het type pakket en de omgeving waar het naar toe moet, in mijn voorbeeld een eigen IIS server

De volgende aanpassingen moet je doen onder tab “Tasks”:

• Onder Deployment process moet je een Website name opgeven (sitenaam in IIS) en deselecteer “Add binding”

• Onder IIS Deployment bij Artifact download selecteer je het buildpakket (.zip) voor deze omgeving

• Onder IIS Web App Manage pas je het fysieke path aan waar de bestanden naartoe verplaatst moeten worden

• Onder IIS Web App Deploy
  • Selecteer onder Package or Folder het .zip bestand wat gepubliceerd moet worden
  • Onder File Transforms & Variable Substitution Options vin kje XML transformation aan

Na bovenstaande stappen kun je je eerste release voor een acceptance omgeving uitvoeren. Je kunt op dezelfde manier in het Pipeline overzicht nog een stage toevoegen met de naam Release. Selecteer daar alle bestanden en definieer de locaties voor de productiesite.

Na het goed instellen van deze omgevingen kun je de eerste release uitvoeren naar twee omgevingen van je applicatie.

Op deze manier is het mogelijk om gestroomlijnd meerdere applicaties voor je klanten vrij te geven. Ook is duidelijk te zien welke code (versie) op welke omgeving staat. Bugfixing en het toevoegen van nieuwe features maakt het hierdoor een stuk eenvoudiger.

Heb je ook een release pipeline ingesteld, maar loop je tegen problemen? Neem dan contact op of laat een reactie achter!