Articles

zurück zum Custom CMS DE
Application Lifecycle Management (ALM) und Power Apps DE
virtuelle Maschinen in Azure - Regionen und Kosten DE
Umbenennen der Azure "Root Management Group" nicht möglich DE
Azure Function in Docker Container ausführen DE
Umbau für "DE"-Inhalte DE

Wie vielleicht jemand bemerkt hat, habe ich seit dem letzten Eintrag, in dem ich erwähnte, dass ich zurück zu WordPress gewechselt habe, nichts mehr veröffentlicht.

Da ich ein technischer Mensch bin, mag ich den Weg, um Inhalte in WordPress einzupflegen, nicht wirklich. In der Zwischenzeit habe ich versucht, dies mit Hilfe des wp cli zu umgehen, was bei nicht sehr gut funktioniert hat.

Deshalb habe ich mich entschlossen, wieder den eines eigenen CMS zu gehen. Diesmal in Python. Für die Speicherung von Inhalten folge ich einem Ansatz, der von Aaron Pericki inspiriert wurde.

Außerdem schaute ich in IndieWeb und entschied mich daher, Inhalte in verschiedene Typen wie Notizen, Artikel und Lesezeichen aufzuteilen. Dadurch wird sich die Feed-Struktur dieser Seite ein wenig ändern. Alle Details zu den Feeds sind hier zu finden.

Wird im Feed Reader nichts geändert, tauchen in Zukunft alle Inhalte in diesem Standard-Feed (/feed) auf.


Einführung

Dieser Artikel wird erklären, wie man Application Lifecycle Management (ALM) in Azure DevOps für Power Apps anwenden kann. Es wird gezeigt wie die benötigte Azure DevOps Umgebung eingerichtet wird. Weiterhin wird beschrieben, wie Quellcode/Power Apps versioniert werden kann/können, Qualitätssicherung durchgeführt und im Anschluss in die Produktionsumgebung ausgeliefert werden kann.

Die Entstehungsgeschichte des Artikels ist länger. Der erste Entwurf wurde von mir schon im Jahr 2019 geschrieben. In der Zwischenzeit habe ich immer wieder daran gearbeitet. Was mich letztendlich von der Veröffentlichung abgehalten hat, war das meiner Meinung nach noch nicht "fertige" Tooling der »Übersicht über Buildtools für Azure DevOps - Power Apps | Microsoft Docs«. Das ursprünglich verfügbare Tooling (Azure DevOps Extension) ist jetzt zwar immer noch verfügbar aber seit dem Sprung auf Version auf 0.3.7 als »DEPRECATED« gekennzeichnet worden. Schon seit dem Versionssprung von 0.1.16 zur Version 0.3.6 wurde das ursprüngliche Tooling grundlegend überarbeitet/verbessert.

In Version 0.1.16 mussten noch zum Einrichten der Verbindung die Zugangsdaten (Benutzername/Passwort) im Klartext hinterlegt werden. Seit der Version 0.3.6 kann diese Authentifizierung endlich mittels Service Principals abgebildet werden.

Authentifizierungsmethoden Abbildung: Authentifizierungsmethoden

Die alte (nicht zu empfehlende) Methode (gelb) steht weiter zur Verfügung. Somit ist der Übergang auf die neue Option (grün) nahtlos möglich, auch für Nutzer die bereits vorherige Versionen der BuildTools verwendet haben oder noch keine Service Principals eingerichtet haben. Beim Umstieg auf die oder Beginn mit der aktuellen Version der Build Tools sollte auf jeden Fall der Wechsel auf die Service Principals erfolgen.

Zwei Versionen sind im Visual Studio Marketplace verfügbar: 1. Power Platform Build Tools - Visual Studio Marketplace
2. (DEPRECATED) PowerApps BuildTools - Visual Studio Marketplace

Wie zuvor beschrieben ist diese Extension [2] mittlerweile als »DEPRECATED« gekennzeichnet, daher sollte nur noch [1] verwendet werden.
Die Werkzeuge, die aktuell für Azure DevOps verfügbar sind, sind grundlegend ein Wrapper um den SolutionPackager für D365 Customer Engagement (CRM).

Die finale Architektur, für die Integration von Azure DevOps und Power Plattform, wird auf abstrakter Ebene wie folgt aussehen.

Architektur Übersicht Abbildung: Architektur Übersicht

Microsoft selbst schlägt zwei verschiedene Vorgehensweisen für ALM in Verbindung mit der Power Plattform vor. [^1] In dieser Anleitung wird die erste Variante beschrieben, bei der nur der Quellcode versioniert wird, aber nicht die gepackten Solutions. Im Kontext klassischer Softwareentwicklung ist dies auch der normale Weg, weil sonst auch nur Quellcode und nicht kompilierte Binaries versioniert werden.

Read more


D2v3 pro Tag

Bei einem möglichen (Teil-)Umzug virtueller Maschinen aus dem eigenen Rechenzentrum (RZ) nach Azure, muss auf jeden Fall auch die Kostenseite betrachtet werden. Hierzu sollten im ersten Schritt die Kosten für den Betrieb der Maschinen im eigenen RZ (direkt [^direkt] und indirekt [^indirekt]) ermittelt werden, damit man diese dann den Kosten (direkt) in Azure gegenüberstellen kann. Bei dieser Gegenüberstellung kann man die in Azure anfallenden Kosten optimieren, in dem für den anfallenden Workload die jeweils passende virtuelle Maschine ausgewählt wird.

Read more


Wenn man damit beginnt sich mit Management Groups in Azure zu beschäftigen, wird man unter Umständen an den Punkt gelangen an dem man die "Root" management group umbenennen möchte. Aber schon die einfache Abfrage der Gruppe wird zu einem Problem führen.

Management Group query error

Damit Modifikationen/Abfragen für diese Management Group möglich sind, muss man zunächst die Zugriffsrechte für die eigenen Account erhöhen, auch wenn man bereits Verzeichnis Administrator ist. Eine entsprechende Meldung wird auch im Azure Portal angezeigt.

Azure Portal hint

Das gesamte Vorgehen hierfür ist im Artikel »Erhöhen der Zugriffsrechte zum Verwalten aller Azure-Abonnements und Verwaltungsgruppen« beschrieben. Hat man die eigenen Zugriffsrechte wie hier beschrieben angepasst bzw. anpassen lassen, kann man die entsprechenden Änderungen vornehmen oder auch nur die Management Group abfragen.

Management Group query success

{{< warning >}} Nachdem man die notwendigen Änderungen mit den erhöhten Zugriffsrechten durchgeführt hat, sollte man die Zugriffsrechte im Nachgang wieder herabsetzen. {{< /warning >}}

Die "Tenant Root Group" lässt sich leider nicht über den Namen in der Azure CLI abfragen bzw. der Name dieser Gruppe ist nicht sprechend. Man kann allerdings mit erhöhten Zugriffsrechten sich alle Management Groups ausgeben lassen und so den Namen dieser speziellen Gruppe in Erfahrung bringen.

az account management-group list

List Management Group


Einleitung

Azure Functions können grundsätzlich auch in Docker ausgeführt werden. Während der Entwicklung kann man diese auch lokal ausführen. In diesem Kontext kommt es aber in Verbindung mit Http Triggern zu einem Problem. Obwohl im monatlich stattfindenden Azure Functions Webcast (Ausgabe 20.02.2020) Verbesserungen im Bereich von Kubernetes Deployments angekündigt wurden, sind dazu bisher keine weiteren Informationen verfügbar bzw. ich habe diese nicht finden können.

Daher zeigt dieser Artikel wie man Azure Functions mit einem Http Trigger Docker betreiben kann.

Read more


Bisher waren Inhalte auf dieser Seite rein in Englisch verfügbar. Dies wird für den Großteil der Inhalte auch so bleiben. Allerdings habe ich in der Vergangenheit gemerkt, dass ich manche technischen und auch nicht technischen Inhalte in Deutsch veröffentlichen würde. Häufig weil diese nur einen Bezug zu Deutschland haben oder weil die technischen Texte, die ich referenzieren möchte, nur auf Deutsch verfügbar sind.

Daher gibt es jetzt auch die "/de" URL.

Die Newsfeeds sind beide getrennt verfügbar. Falls jemand Interesse an Inhalten beider Sprachen hat, müssen auch beide RSS-Feeds abonniert werden.