Am Puls von Microsoft

Entwicklertagebuch MyLife #4: Azure wir kommen!

Entwicklertagebuch MyLife #4: Azure wir kommen!

Eine praktische Lösung für ein Problem zu finden, welche man sich selbst beschert hat, bietet ein gewisses Genugtun. Im letzten Artikel dieser Reihe zu MyLife.NET sprachen wir über die Einschränkungen, welche Blazor.WASM mit sich bringt. Nun habe wir mit GitHub und Azure eine Lösung hierfür parat. Was für ein Entwicklerträumchen.

Für alle, denen diese Artikelreihe noch unbekannt ist – das habt ihr bislang verpasst, könnt euch aber natürlich nachträglich einlesen:

Was war das Problem?

Im Teil 3 unserer Artikelreihe habe ich festgestellt, dass ein Blazor WebAssembly-Projekt bzw. allgemein auch ein JavaScript, was lokal auf dem Client läuft, dank des Sicherheitsmechanismus namens CORS nur auf Daten auf derselben Domain zugreifen kann. Dies war insofern ein Problem, da die Datengrundlage für MyLife.NET auch verteilt abgelegt sein kann – vor allem im Hinblick auf den Zugriff auf Feeds von YouTube, Medium und anderen Plattformen. Der Plan ging also nach hinten los. Es musste eine Lösung her, welche alle Daten im Domain-lokalen Kontext bereitstellt und, genauso wichtig, diese aktuell zu halten.

Zeit für eine neue JSON-Datei!

Wie im ersten Teil angesprochen war ich mir nicht sicher, wie viele Daten in die zentrale JSON-Datei von MyLife.NET gepackt werden sollten. Schlussendlich entschied ich mich, für die benötigte Zusammenfassung meiner digitalen Veröffentlichungen eine zweite JSON- Struktur und damit Datei anzulegen mit dem Namen “cc-publications.json”. Diese neue Datei wird mit dem bekannten Exporter.cs basierend auf den hinterlegten Content Creation Accounts des „life.json„-Objektes erstellt und mit dem in allen Subprojekten verfügbaren „LifeService.cs“ abgerufen. Ob es hier Sinn macht, auch auf Service-Ebene den Kontext zu trennen, wird die Zeit zeigen. Im Moment ist es das, mit dem man am simpelsten Arbeiten kann, jedoch muss der einfachste Weg nicht immer der sein, den man gehen sollte.

Apropos einfach: Die neue Struktur baut auf bereits bekannten Models auf und lässt sich somit leicht integrieren, ohne doppelte Klassen dafür erstellen und warten zu müssen.

GitHub Actions – das Schweizer Messer der Automation

Somit ist nun geklärt, wie man diese Datei erstellt, doch noch nicht, wie man sie auch aktuell mit den neusten Veröffentlichungen hält. Hier kam ich zum Schluss, dass GitHub Actions ideal sind. Ein Runner in der Cloud, welcher einmal am Tag den Exporter anstößt und die entsprechenden Dateien schlussendlich am richtigen Ort im wwwroot/ von MyLife.Blazor.Wasm mittels eines Git Commit und Push Befehles ablegt. Dieser Push wiederum löst eine weitere Action aus, welche die öffentlich erreichbare GitHub Page aktualisiert und somit die frisch eingepflegten Daten der Umwelt zur Verfügung stellt.

Um nun der Faden der Automation weiter zu spinnen, wird nicht nur die statische Seite auf GitHub aktualisiert, sondern auch direkt zu einer Azure Static Web App Ressource deployed. Somit können wir uns nun alle ein bisschen Business fühlen und mit unserer kleinen Bastelei in das gigantische Azure-Ökosystem hineinschnuppern.

Azure für Bastler? Aber sicher!

In meiner Wahrnehmung war Azure noch nie etwas für Bastler und Maker, sondern eher für Firmen und Enterprises, welche das große Programm benötigen und nicht in Angst leben müssen, dass ein falscher Klick die Kreditkarte in Flammen aufgehen lässt. Nun, das mag weiter stimmen, doch hat Microsoft über die Jahre das “Hobby”-Angebot, in anderen Worten den “Gratis”-Plan an verfügbaren Ressourcen, immer weiter erweitert, so dass man heutzutage auf Azure auch als Bastler noch mal einen Blick zu werfen sollte.

Ein Bestandteil des Hobby-Plans sind die Static Web Apps, welche im Prinzip das Azure-Pendant zu GitHub Pages sind, sich auf Wunsch jedoch viel fein granularer konfigurieren und in die bestehende (Unternehmens-) Infrastruktur einbetten lassen.

Überraschend einfach einzurichten

Eine Überraschung gleich zu Anfang: Die Einrichtung war kinderleicht, solang man genau liest, was dort steht. Der Wizard, welcher einen durch die Erstellung einer neuen Static Web App führt, ist selbsterklärend, dennoch vollgepackt mit Informationen und Auswahlmöglichkeiten, welche man erst einmal verstehen und verdauen muss.

Wörter wie “Ressourcen Gruppe”, “Pay-as-you-go“ und Co haben mich erst sehr abgeschreckt, weiter in die Thematik einzusteigen. Diese Angst wurde mir im Laufe des Wizards genommen, indem klar gemacht wird, dass ich – solange ich es nicht anders möchte – die Web-App im Hobby-Plan-Modus starte, welcher frei von Kosten ist. Natürlich kommt dieses “gratis” mit Einschränkungen, welche mir als Bastler im Sinne von Bandbreite oder beispielsweise Datenvolumen erstmal vollkommen egal sein können.

Azure <3 GitHub

Mittlerweile merkt man stark, dass GitHub zu Microsoft gehört und eventuell auch eine höhere Priorität als die davor bestehende Entwickler Plattform Azure DevOps aka Team Foundation hat. Wieso sonst wird GitHub vor Azure DevOps aufgeführt? Wir werden es nie wissen.

Azure erkennt nach Auswahl des Repositoriums direkt, um welche Art von Static Web App es geht, in unserem Falle um eine Blazor App, und schlägt uns brauchbare Konfigurationswerte vor. Wie auf den Bildschirmfotos zu sehen, fällt schlussendlich eine GitHub Action-Datei heraus, mit welcher beispielsweise mit jedem Push in das GitHub Repository auch ein Update der Azure Static Web App angestoßen wird. Dies nenne ich eine nahtlose Integration zweier Dienste mit einem wirklichen Mehrwert für den Entwickler – und ich muss nochmal betonen, wie unkompliziert und schmerzfrei dies mittlerweile alles möglich ist!

Weitere Azure Integrationen in MyLife denkbar

Im Laufe der Zeit sind weitere Azure-Integrationen in MyLife denkbar. Ein Punkt wäre ein NoBrainer gewesen, wenn Microsoft es nicht abgesägt hatte: AppCenter Analytics, um Interaktionen der Benutzer mit der Webseite und den entstehenden Apps erfassen zu können. Es ist also nicht alles Gold in der blauen Cloud – dem muss man sich allgemein einfach bewusst sein. Nichtsdestotrotz hat der “Hobby”-Plan noch viele weitere Produkte in Petto, welche man im Kontext von MyLife einmal ansehen könnte.

Habt ihr Wünsche oder Ideen, welches Azure-Produkt ich einmal ansehen sollte? Generell sind für eine “nicht-WASM”-Blazor-Variante auch eine CosmoDB gepaart mit Azure Functions denkbar.

Ihr habt Lust mitzuwirken?

Falls ihr euch beteiligen wollt, weil ihr mir zeigen wollt, wie etwas richtig oder einfacher geht oder ihr euch zum ersten Mal an einer noch übersichtlichen .NET-Solution beteiligen wollt, seid ihr herzlich eingeladen, auf GitHub vorbeizusehen, das Repository zu forken, Issues mit Problemen oder Hinweisen zu eröffnen oder einfach zu stöbern. Wir alle sind hier, um zu lernen und, noch wichtiger, um Spaß an der Softwareentwicklung zu haben!

Artikel im Forum diskutieren (0)

Über den Autor

Tobias Scholze

Tobias Scholze

Bayrischer Open Source- und Community-Enthusiast, Verfechter des neuen Microsoft und Wandler zwischen den Betriebssystemwelten. #communityrocks Von Herzen ein Nerd mit der festen Überzeugung, dass man gemeinsam und durch den Einsatz von moderner IT die Welt für jeden ein Stückchen besser machen kann.

Anzeige
Anzeige