CONNECTED Conference 2023 - Aufzeichnungen jetzt hier verfügbar +++                     

Suche

über alle News und Events

 

Alle News

 

Vom 5. bis 7. Juni findet in London wieder die...

Weiterlesen

Live Coding on stage in Hamburg - exklusiv für...

Weiterlesen

Um Azure Ressourcen von DevOps aus zu deployen,...

Weiterlesen

In diesem Artikel wird ein beispielhafter Aufbau...

Weiterlesen

Die QUIBIQ Gruppe wurde am 9. März 2023 von dem...

Weiterlesen

Der Schnelleinstieg in die Welt der Tests für den...

Weiterlesen

Wenn man eine, im Azure Portal, entwickelte Logic...

Weiterlesen

WinSCP für BizTalk wird für den SFTP-Adapter...

Weiterlesen

Mit diesem Artikel wird ein klares Verständnis von...

Weiterlesen

In einer Logic App werden häufig Variablen...

Weiterlesen

How-to: Wie lassen sich die guten Prinzipien der CI/CD-Pipelines bei Logic Apps und API Management realisieren?

Mit Logic Apps lassen sich ja wunderbar sehr schnell Systeme miteinander verbinden und einfache Prozesse implementieren. Logic Apps können per http aufgerufen werden, allerdings erkennt man ihrer URL nicht an, ob sie aus Test oder Produktion kommt – und was sie macht. Deshalb bietet sich an, die Logic App mit Azure API Management gut strukturiert verfügbar zu machen. Die nötige Sicherheit lässt sich dann auch noch bewerkstelligen. Wie sorgt man jetzt aber eigentlich dafür, dass der Code sich auf andere Stages erweitern lässt und in die üblichen Application Lifecycle-Prozesse einbindet? Genau das wollen wir in diesem Blogpost erklären...

Wie lassen sich die guten Prinzipien der CI/CD-Pipelines bei Logic Apps und API Management realisieren

Bevor wir anfangen, hier ganz kurz, warum wir diesen beiden Wege nicht beschreiten konnten:

Deshalb haben wir es anders gemacht: Wir werden ein Template erstellen, parametrisieren und in einem Projekt ablegen; und darauf dann eine CI/CD-Pipeline mit Azure DevOps aufbauen.

Die wunderbare Johanna aka Schlogger hat unser Vorgehen in folgendes Bild gegossen:



Aber erstmal der Reihe nach:


Templates exportieren

Als erstes exportiert man das Template mit den Azure-Objekten. In unserem Fall beinhaltet die Ressourcegruppe eine Logic App, welche auf Salesforce zugreift und das API Management, in das es eingebunden sind. Die Objekte sind also:

  • Logic App
  • API Connection zu Salesforce
  • API Management

Dafür öffnet man die Ressourcegruppe und klickt auf „Export template“:



Das Template wird generiert und enthält die Spezifikationen für die drei Objekte. Vorsicht: Die Credentials für die API Connection wurden nicht erstellt – diese müssen manuell eingegeben werden. Man klickt auf „Download“, um das Template (template.json)  und die Parameter (parameters.json) gezippt runterladen zu können.

Mehr Infos befinden sich hier:
https://docs.microsoft.com/en-us/azure/logic-apps/logic-apps-create-deploy-template


Deployment-Projekt erstellen

Theoretisch reicht für das Deployment mit CI/CD-Pipelines die JSON-Files, aber ich möchte die Dateien sicher in meiner Sourcecode-Verwaltung ablegen und so erstelle ich mir ein Deployment-Projekt.

Um eine Azure-Ressourcengruppe in Visual Studio zu erstellen, muss man die Azure Resource Manager Tools installieren. Wenn VS beim Installieren nach dem Template fragt, kann man erstmal mit einem leeren „Blank Template“ starten.



Einige Dateien werden direkt erstellt. Diese sollte man umbenennen, um sie eindeutig zu machen, auch wenn weitere Templates hinzukommen. „Azuredeploy.json“ enhält das Template, und das Parameterfile entsprechend die Parameter. Ich würde es in „template.json“ umbenennen. Die Parameterdatei vervielfacht man pro Stage, um sie individuell anzupassen:

  • template.prod.parameters.json
  • template.test.parameters.json
  • template.dev.parameters.json

Als nächstes kann man die Dateien durch die gezippten Dateien ersetzen und die Werte anpassen, so dass es zu der Stage passt.

Der Name des API Management muss zwischen den Stages voneinander abweichen, weil das API Management nur Azure-weit eindeutige Namen akzeptiert, weil für jedes API Management eine Subdomain für azure-api.net erstellt wird. Alle Referenzen im Template müssen also angepasst werden. Dann checkt man die Dateien in das DevOps Repository ein.


Continuous Integration aufbauen

Zum Aufbau der CI öffnet man in Azure DevOps “Pipelines/Builds”. Dort erstellt man eine neue Build-Pipeline und wählt “Azure Repos Git” als Input aus:

Hier ist das Repo auszuwählen und auf der folgenden Seite das „Azure Resource Group Deployment“.

Man kann es so einrichten:

azureSubscription: Your Subscription (Needs to validate)

    action: 'Create Or Update Resource Group'

    resourceGroupName: A resource group

    location: Your location

    templateLocation: 'Linked artifact'

    csmFile: Path to your template, current location next to your solution

    csmParametersFile: Path to your parameters, same as before

    deploymentMode: 'Validation'

Ich würde es erstmal auf “Validation only” setzen, um sicherzustellen, dass die Dateien korrekt erstellt werden.

Dann publiziert man das Template als “Build Artifact”. Dafür füllt man die Felder entsprechend:

    PathtoPublish: Path to your template, same as above

    ArtifactName: 'Template'

    publishLocation: 'Container'


Man wiederholt das für die Parameter und klickt “Save”.

Ein Build sollte automatisch starten – und hoffentlich funktionieren. Das sieht dann so aus:



 

Release Pipeline aufbauen

 

Um die Release Pipeline aufzubauen, navigiert man zu „Pipelines/Releases“. Man startet am besten mit einem “Empty Job” bei der Auswahl des Templates.

Man wählt “Add an Artifact” aus, um die erstellte Build Definition zu öffnen.




 

Dann klickt man auf Stage 1 und nenne sie um, z.B. „Deploy Template”.

Standardmäßig wird diese Stage beim Builden gestartet. Wenn dies manuell gestartet werden soll, kann man das auf dem „Blitz“-Icon einrichten.

Im Tasks-Menü kann man den Stage-Namen auswählen (bei uns jetzt „Deploy template“). Mit “+” kann man einen neuen Job erstellen und dort “Azure Resource Group Deployment” auswählen.


Dort konfiguriert man folgende Dinge:

  • Azure Subscription: die Azure Subscription, in die man deployen möchte
  • Action: Create oder Update, je nachdem
  • Resource group: Die Ressourcegruppe, in die man deployen möchte
  • Location: Ort der Ressourcegruppe
  • Template location: Das verlinkte Artefakt
  • Template: Das erstellte Template sollte erscheinen, wenn man auf „…“ klickt
  • Template parameters: dito
  • Deployment mode: “Incremental”, falls man updaten möchte oder “complete”, um alles erstmal zu löschen, was da ist.

Und zum Schluß: Testen

Um die CI/CD-Pipeline zu testen, klickt man auf “Pipelines/Builds” > “Queue”. Wenn der Build erfolgreich gebaut wurde, wird die Release Pipeline automatisch deployen – es sei denn, man hat den Deploymen-Trigger vorher auf „manuell“ gestellt.

Jetzt musst du nur noch prüfen, ob alles installiert wurde, wie du wolltest.


Fazit

CI/CD-Pipelines sind mit Azure DevOps sehr gut möglich zu realisieren und auch für API Management und Logic Apps einfach machbar. Application Lifecycle Managemt ist also auch in der Cloud gut realisierbar. Selbst das API Management als „Consumption tier“ lässt sich damit einfach auf verschiedene Stages ausrollen und damit in ein globales Release Management einbaubar.

Mehr zum Thema und zu hybrider Integration findet ihr auf unserer Website oder kontaktiert mich gerne direkt.

Vielen Dank an dieser Stelle an die QUIBIQ-Kollegen (v.a. Christoph Hanser), um das Thema mal zusätzlich zu einer Kundenanforderung ausgiebig umsetzen zu lassen.

Ihre Kontaktmöglichkeiten

Sie haben eine konkrete Frage an uns


 

Bleiben Sie immer auf dem Laufenden


 

Mit meinem "Ja" erkläre ich mich mit der Verarbeitung meiner Daten zur Zusendung von Informationen einverstanden. Ich weiß, dass ich diese Erklärung jederzeit durch einfache Mitteilung widerrufen kann. Bei einem Nein an dieser Stelle erhalte ich zukünftig keine Informationen mehr.

© QUIBIQ GmbH · Impressum · Datenschutz