Findings and thingies - Articles (de)https://andre.bering.in/articles-feed/de http://www.rssboard.org/rss-specificationdeWed, 27 Jan 2021 00:29:24 +0000zurück zum Custom CMShttps://andre.bering.in/2021/01/12/1/<p>Wie vielleicht jemand bemerkt hat, habe ich seit dem letzten <a href="/posts/2020-09-14-back-to-wordpress">Eintrag</a>, in dem ich erwähnte, dass ich zurück zu WordPress gewechselt habe, nichts mehr veröffentlicht.</p> <p>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 <code>wp cli</code> zu umgehen, was bei nicht sehr gut funktioniert hat.</p> <p>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 <a href="https://aaronparecki.com/">Aaron Pericki</a> inspiriert wurde.</p> <p>Außerdem schaute ich in <a href="https://indieweb.org/">IndieWeb</a> und entschied mich daher, Inhalte in verschiedene Typen wie Notizen, Artikel und Lesezeichen aufzuteilen. <strong>Dadurch wird sich die Feed-Struktur dieser Seite ein wenig ändern. Alle Details zu den Feeds sind <a href="/feeds/">hier</a> zu finden.</strong></p> <p>Wird im Feed Reader nichts geändert, tauchen in Zukunft alle Inhalte in diesem Standard-Feed (<a href="/feed">/feed</a>) auf.</p>https://andre.bering.in/2021/01/12/1/Tue, 12 Jan 2021 12:00:00 +0000Application Lifecycle Management (ALM) und Power Appshttps://andre.bering.in/de/posts/2020-08-11-application-lifecycle-management-alm-und-power-apps/<h2>Einführung</h2> <p>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.</p> <p>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 "<strong>fertige</strong>" Tooling der »<a href="https://docs.microsoft.com/de-de/powerapps/developer/common-data-service/build-tools-overview">Übersicht über Buildtools für Azure DevOps - Power Apps | Microsoft Docs</a>«. 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. </p> <p>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 <a href="https://docs.microsoft.com/de-de/azure/active-directory/develop/app-objects-and-service-principals">Service Principals</a> abgebildet werden.</p> <p><img alt="Authentifizierungsmethoden" class="lb lb-img-noborder" lb-cust-margin="lb-cust-margin" noborder="yes" src="/2020/08/11/1/devops-principal.png" width="100%" /> <em>Abbildung: Authentifizierungsmethoden</em></p> <p>Die alte (<strong><ins>nicht zu empfehlende</ins></strong>) 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. <strong>Beim Umstieg auf die oder Beginn mit der aktuellen Version der Build Tools sollte auf jeden Fall der Wechsel auf die Service Principals erfolgen</strong>.</p> <p>Zwei Versionen sind im Visual Studio Marketplace verfügbar: 1. <strong><a href="https://marketplace.visualstudio.com/items?itemName=microsoft-IsvExpTools.PowerPlatform-BuildTools&amp;targetId=e326b11d-3605-4a6e-903e-4bff6ccc155d&amp;utm_source=vstsproduct&amp;utm_medium=ExtHubManageList">Power Platform Build Tools - Visual Studio Marketplace</a></strong><br /> 2. (<strong>DEPRECATED</strong>) <a href="https://marketplace.visualstudio.com/items?itemName=microsoft-IsvExpTools.PowerApps-BuildTools&amp;targetId=e326b11d-3605-4a6e-903e-4bff6ccc155d&amp;utm_source=vstsproduct&amp;utm_medium=ExtHubManageList">PowerApps BuildTools - Visual Studio Marketplace</a></p> <p>Wie zuvor beschrieben ist diese Extension [2] mittlerweile als »<strong>DEPRECATED</strong>« gekennzeichnet, daher sollte nur noch [1] verwendet werden.<br /> Die Werkzeuge, die aktuell für Azure DevOps verfügbar sind, sind grundlegend ein Wrapper um den SolutionPackager für D365 Customer Engagement (CRM).</p> <p>Die finale Architektur, für die Integration von Azure DevOps und Power Plattform, wird auf abstrakter Ebene wie folgt aussehen.</p> <p><img alt="Architektur Übersicht" class="lb lb-img-noborder" lb-cust-margin="lb-cust-margin" noborder="yes" src="/2020/08/11/1/architecture.png" width="100%" /> <em>Abbildung: Architektur Übersicht</em></p> <p>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 <em>normale</em> Weg, weil sonst auch nur Quellcode und nicht kompilierte Binaries versioniert werden.</p> <!-- more --> <h2>Anforderungen</h2> <p>Grundlegend werden einige Dinge benötigt, um die Schritte nachvollziehen zu können. Die nachfolgende Komponenten werden benötigt.</p> <ul> <li>3 Power Apps Umgebungen (bspw. <a href="https://docs.microsoft.com/en-us/office/developer-program/office-365-developer-program-get-started">Microsoft 365-Entwicklerabonnements</a> mit drei Konten im Tenant jeweils mit <a href="https://powerapps.microsoft.com/de-de/communityplan/">Power Apps-Communityplan</a> verbunden)</li> <li>1 Azure DevOps Projekt</li> <li>installierte <a href="https://docs.microsoft.com/de-de/powerapps/developer/common-data-service/build-tools-overview">Power Apps build tools Azure DevOps Erweiterung</a></li> <li>1 Git Repository</li> <li>1 Service Principal</li> </ul> <aside class="article-alert article-alert-warning"> <div class="alert-warning-icon"> <img src="/img/exclamation.svg" /> </div> <div class="alert-warning-content"> Wenn ein Microsoft 365-Entwicklerabonnement eingesetzt wird, muss Klarheit darüber bestehen, dass dieses nach 90 Tagen abläuft, falls keine M365 Entwicklung durchgeführt wurde. Für die Verlängerung ist es ausreichend, dass bspw. ein <a href="https://docs.microsoft.com/de-de/sharepoint/dev/spfx/web-parts/get-started/build-a-hello-world-web-part">SharePoint Web Part</a> erstellt/entwickelt wird. </div> </aside> <h2 id="getting-started">Los geht's</h2> <p>Wie zuvor erwähnt werden drei Umgebungen benötigt, um dieser Anleitung folgen zu können. Für die nachfolgenden Schritte werden die folgenden Umgebungen mit der entsprechenden Bedeutung verwendet.</p> <table> <thead> <tr> <th>Name</th> <th align="center">Function</th> </tr> </thead> <tbody> <tr> <td>André Bering's Environment</td> <td align="center">DEV</td> </tr> <tr> <td>Johanna Lorenz's Environment</td> <td align="center">BUILD/QA</td> </tr> <tr> <td>Alex Wilber's Environment</td> <td align="center">PROD</td> </tr> </tbody> </table> <p>Wie zu sehen ist, sind diese drei Umgebungen im <a href="http://aka.ms/ppac">Power Platform Admin Center</a> sichtbar.</p> <p><img alt="Umgebungsübersicht" class="lb lb-img-noborder" lb-cust-margin="lb-cust-margin" noborder="yes" src="/2020/08/11/1/environment-overview.png" width="100%" /> <em>Abbildung: Umgebungsübersicht</em></p> <p>Mit einem Hintergrund als Entwickler kommt als erstes vielleicht die Frage auf, wie die Arbeit in der Power Platform versioniert werden kann. Zur Zeit gibt es leider keinen einfachen Weg dies zu tun. Der einzige Weg ist manuell die Lösung herunterzuladen, diese zu entpacken und die Inhalte dann zu versionieren.</p> <p>Dieser Prozess kann mittels ALM in Azure DevOps abgebildet werden, sogar mit einer Art von CI/CD Ansatz.<br /> Der Artikel basiert in der Hauptsache auf dem Tutorial von Microsoft für die Power Apps Build Tools, das <a href="https://github.com/microsoft/PowerApps-Samples/tree/master/build-tools">hier</a> zu finden ist.</p> <p>Für das Tutorial und die weiteren Schritte wird die URL der jeweiligen Umgebung benötigt. Die URL ist im <a href="https://aka.ms/ppac">Admin Center</a> zu finden.</p> <p><img alt="Admin Center - Environment URL" class="lb lb-img-noborder" lb-cust-margin="lb-cust-margin" noborder="yes" src="/2020/08/11/1/environment-url.png" width="100%" /> <em>Abbildung: Admin Center - Environment URL</em></p> <p>Falls irgendeine Form von ALM mit Power Apps eingesetzt werden soll, muss zunächst verstehen werden wie Lösungen in diesem Kontext funktionieren. Um diese Grundlagen zu verstehen kann dieser Microsoft Docs Artikel gelesen werden: <a href="https://docs.microsoft.com/de-de/powerapps/maker/common-data-service/solutions-overview">Arbeiten mit Lösungen in Power Apps - Power Apps | Microsoft Docs</a></p> <p>In diesem Artikel ist noch eine weitere Einführung verlinkt, die auch gelesen werden sollte: <a href="https://docs.microsoft.com/de-de/powerapps/developer/common-data-service/introduction-solutions">Einführung in Lösungen - Power Apps | Microsoft Docs</a></p> <h2 id="service-principal">Service connections / Service Principals</h2> <p>Um die Verbindung in Azure DevOps einrichten zu können, muss der entsprechende Service Principal in Azure DevOps eingerichtet bzw. hinterlegt werden werden. Den entsprechenden Menüpunkt befindet sich unterhalb von »<em><strong>Project Settings - Pipelines - Service connection - New service connection</strong></em>«.</p> <p><img alt="Azure DevOps Service - Create new service connection" class="lb lb-img-noborder" lb-cust-margin="lb-cust-margin" noborder="yes" src="/2020/08/11/1/create-new-sc.png" width="100%" /> <em>Abbildung: Azure DevOps Service - Create new service connection</em></p> <p><img alt="Azure DevOps Service - Create new service connection" class="lb lb-img-noborder" lb-cust-margin="lb-cust-margin" noborder="yes" src="/2020/08/11/1/create-serviceconnection.png" width="100%" /> <em>Abbildung: Azure DevOps Service connections</em></p> <p>Im Dialog wird auf zwei Stellen verwiesen, die helfen sollen, den entsprechenden Zugang anzulegen bzw. an der richtigen Stelle zu hinterlegen. Der erste Link verweist auf eine Anleitung in Microsoft Docs. Dort wird empfohlen die Anlage mittels verlinktem PowerShell-Skript durchzuführen. Das Skript kann allerdings nur unter Windows ausgeführt werden, weil die verwendeten PowerShell Module zwingend »System.Forms« benötigen und eben diese nur unter Windows zur Verfügung stehen. Daher empfehle ich, dass der Service Principal direkt im Azure Portal erzeugt wird. Die entsprechende Dokumentation ist im Fließtext der Anleitung verlinkt.</p> <p>{{&lt; warning &gt;}} Der Service Principal muss in dem Tenant angelegt werden, in dem sich die Power Apps Umgebungen befinden. {{&lt; /warning &gt;}}</p> <p><a href="https://docs.microsoft.com/de-de/powerapps/developer/common-data-service/use-single-tenant-server-server-authentication#azure-application-registration">Verwenden der Einzel-Mandanten-Server-zu-Server-Authentifizierung (Common Data Service) - Power Apps | Microsoft Docs</a></p> <p>Nachdem der/die Service Principal/s in Azure in angelegt wurden, kann die Einrichtung fortgesetzt werden.</p> <p>Entscheidend ist, dass es <strong>nicht</strong> wie in der Anleitung den Punkt »<strong>Settings</strong>« gibt, sondern den Punkt »<strong>Advanced Settings</strong>«. Über diesen Punkt kann die entsprechende Oberfläche aufgerufen werden. </p> <p><img alt="Einstellungen - Erweiterte Einstellungen" class="lb lb-img-noborder" lb-cust-margin="lb-cust-margin" noborder="yes" src="/2020/08/11/1/01-create-sp.png" width="100%" /> <em>Abbildung: Einstellungen - Erweiterte Einstellungen</em></p> <p>An dieser Stelle kann Verwunderung eintreten, wenn die Dynamics 365 Oberfläche erscheint. Die beiden Plattformen sind sehr eng miteinander verzahnt, so dass bestimmte Einstellungen aktuell nur (immer noch) in der <em>alten</em> Oberfläche zu finden sind. Die Umstellung auf eine durchgehende Verwaltungsoberfläche ist ein fortlaufender Prozess. Daher ist davon auszugehen, dass die Punkte in Zukunft auch in die Power Plattform Oberfläche bzw. ein einheitliches Look &amp; Feel integriert werden.</p> <p>In der Microsoft Dokumentation gibt es noch einen Stolperstein, nämlich bei der Anlage des Benutzers. Das Verhalten hinsichtlich dieses Stolpersteins war aber nicht konsistent.<br /> Daher nachfolgend die einzelnen Dialoge, die abgearbeitet werden müssen, um den Service Principal innerhalb der Power Plattform Umgebung bekannt zu machen. </p> <p><img alt="D365 Settings" class="lb lb-img-noborder" lb-cust-margin="lb-cust-margin" noborder="yes" src="/2020/08/11/1/02-create-sp.png" width="100%" /> <em>Abbildung: D365 Settings</em></p> <p><img alt="D365 Security" class="lb lb-img-noborder" lb-cust-margin="lb-cust-margin" noborder="yes" src="/2020/08/11/1/03-create-sp.png" width="100%" /> <em>Abbildung: D365 Security</em></p> <p>In der Benutzerliste Ansicht auf »Application Users« filtern und im Anschluss »+ NEW« klicken.</p> <p><img alt="Benutzeransicht filtern" class="lb lb-img-noborder" lb-cust-margin="lb-cust-margin" noborder="yes" src="/2020/08/11/1/04-create-sp.png" width="100%" /> <em>Abbildung: Benutzeransicht filtern</em></p> <p>Vor der Eingabe der Daten muss der Dialog noch mittels Auswahl von »Application User« auf den richten Modus umgestellt werden.</p> <p><img alt="Auswahl 'Application User'" class="lb lb-img-noborder" lb-cust-margin="lb-cust-margin" noborder="yes" src="/2020/08/11/1/05-create-sp.png" width="100%" /> <em>Abbildung: Auswahl 'Application User'</em></p> <p>Bei der Eingabe der Daten müssen die Informationen verwendet werden, die man zuvor bei Anlage des Service Principal im Azure Portal definiert hat. Der Benutzer benötigt (weil es ein Pflichtfeld der Form ist) ebenfalls eine E-Mail Adresse, auch wenn es sich nur um einen technischen Benutzeraccount handelt. Hier können bspw. Adressen sogenannter Beispieldomains (<a href="https://de.wikipedia.org/wiki/Beispieldomains">Beispieldomains – Wikipedia</a>) verwendet werden, wie auch im folgenden Screenshot zu sehen ist. Die Adresse wird aber nicht für den Versand von E-Mails verwendet.<br /> Nach Anlage des Benutzers durch Betätigen der Schaltfläche »SAVE« den Dialog <strong>nicht</strong> schließen.</p> <p><img alt="Eingabe Benutzerdaten" class="lb lb-img-noborder" lb-cust-margin="lb-cust-margin" noborder="yes" src="/2020/08/11/1/06-create-sp.png" width="100%" /> <em>Abbildung: Eingabe Benutzerdaten</em></p> <p>Über die Schaltfläche »MANAGE ROLES« muss dem Benutzeraccount noch die notwendige Rolle zugewiesen werden.</p> <p><img alt="Rollenzuweisung aufrufen" class="lb lb-img-noborder" lb-cust-margin="lb-cust-margin" noborder="yes" src="/2020/08/11/1/07-create-sp.png" width="100%" /> <em>Abbildung: Rollenzuweisung aufrufen</em></p> <p>Damit alle notwendigen Aktionen mit diesem Benutzeraccount durchgeführt werden können, muss die Rolle »System Administrator« zugewiesen werden. Ansonsten kommt es später im Kontext der Verwendung durch die Azure DevOps Pipelines zu Fehlern.</p> <p><img alt="Auswahl Benutzerrolle" class="lb lb-img-noborder" lb-cust-margin="lb-cust-margin" noborder="yes" src="/2020/08/11/1/08-create-sp.png" width="100%" /> <em>Abbildung: Auswahl Benutzerrolle</em></p> <p>Nach diesen Schritt ist der Zugang eingerichtet und kann nun in Azure DevOps hinterlegt werden. Hierzu muss der Dialog verwendet werden, der zu Beginn dieses Abschnitts (»<a href="{{&lt; ref &quot;#service-principal&quot; &gt;}}">Service connections / Service Principals</a>«) zu sehen/beschrieben ist.</p> <p>Für jede Power Plattform Umgebung muss eine individuelle Service Connection angelegt werden. Insgesamt muss die zuvor beschriebene Einrichtung drei Mal vorgenommen, wobei der Service Principal nicht drei Mal angelegt werden muss. Dieser kann in jeder Umgebung als Benutzeraccount hinterlegt werden.<br /> Alternativ kann natürlich auch pro Umgebung jeweils ein separater Service Principal angelegt werden.</p> <p><img alt="Azure DevOps Service connections Liste" class="lb lb-img-noborder" lb-cust-margin="lb-cust-margin" noborder="yes" src="/2020/08/11/1/devops-service-connections-list.png" width="100%" /> <em>Abbildung: Azure DevOps Service connections Liste</em></p> <p>Danach alle benötigten Verbindungen mit den jeweiligen Informationen/Zugangsdaten pro Umgebung anlegen.</p> <p><img alt="Azure DevOps Service connection Eigenschaften" class="lb lb-img-noborder" lb-cust-margin="lb-cust-margin" noborder="yes" src="/2020/08/11/1/devops-service-connections-properties.png" width="50%" /> <em>Abbildung: Azure DevOps Service connection Eigenschaften</em></p> <p>Wie im Abschnitt »<a href="{{&lt; ref &quot;#getting-started&quot; &gt;}}">Los geht's</a>« beschrieben, wird die URL der Umgebung benötigt und dieser Wert wird als »<em><strong>Server URL</strong></em>« in Eigenschaften der Service Connection hinterlegt.</p> <h2>Azure DevOps Pipelines</h2> <h3>Einleitung</h3> <p>Nach Anlage der Service Connections müssen jetzt die Pipelines und Releases eingerichtet werden. Diese werden genutzt um den Quellcode aus »DEV« zu extrahieren, eine Managed Solution in »QA/Build« zu erzeugen und diese Solution dann in »PROD« auszurollen.</p> <p>Für die ersten beiden Schritte wird jeweils eine Pipeline benötigt.</p> <p><img alt="Liste Azure DevOps Pipelines" class="lb lb-img-noborder" lb-cust-margin="lb-cust-margin" noborder="yes" src="/2020/08/11/1/pipelines-list.png" width="100%" /> <em>Abbildung: Liste Azure DevOps Pipelines</em></p> <p>Für das letztendliche Deployment Richtung PROD wird dann ein Azure DevOps Release verwendet.</p> <p><img alt="Liste Azure DevOps Releases" class="lb lb-img-noborder" lb-cust-margin="lb-cust-margin" noborder="yes" src="/2020/08/11/1/releases-list.png" width="100%" /> <em>Abbildung: Liste Azure DevOps Releases</em></p> <h3>Berechtigungen Repository</h3> <p>Unterhalb von »<em><strong>Project Settings - Repos - Repositories User</strong></em>« muss dem Account »<em><strong>\&lt;Azure DevOps Project Name> Build service (\&lt;Organization name>)</strong></em>« die »<em><strong>Contribute</strong></em>« Berechtigung erteilt werden. Andernfalls kann die Build Pipeline nicht den Quellcode in das Repository pushen.</p> <p><img alt="'Build Service' Berechtigungen" class="lb lb-img-noborder" lb-cust-margin="lb-cust-margin" noborder="yes" src="/2020/08/11/1/build-service-permission.png" width="100%" /> <em>Abbildung: 'Build Service' Berechtigungen</em></p> <h3>Lösung exportieren</h3> <p>In der Pipeline für den Export der Solution sind vier Schritte und ein weiterer für das hinzufügen des Code zum Repository notwendig.</p> <p><img alt="Azure DevOps Pipeline Tasks" class="lb lb-img-noborder" lb-cust-margin="lb-cust-margin" noborder="yes" src="/2020/08/11/1/export-from-dev.png" width="100%" /> <em>Abbildung: Azure DevOps Pipeline Tasks</em></p> <p>Um den Quellcode zum Repository hinzuzufügen, sind ein paar Kommandozeilenbefehle notwendig, damit Git automatisiert im Kontext der Pipeline ausgeführt wird.</p> <p><img alt="Azure DevOps Pipeline Command line task" class="lb lb-img-noborder" lb-cust-margin="lb-cust-margin" noborder="yes" src="/2020/08/11/1/task-add-source-code.png" width="100%" /> <em>Abbildung: Azure DevOps Pipeline Command line task</em></p> <p>Hervorzuheben ist hierbei die Variable. Diese muss/kann beim Starten der Queue gesetzt werden. Somit kann der jeweiligen Commit-Kommentar immer dynamisch beim jeweiligen Durchlauf gesetzt werden. Der Code für diesen Task findet sich im folgenden Abschnitt.</p> <h4>Quellcode in Repository</h4> <p>Der Code wird im letzten Schritt »Commit solution to repo« verwendet, um den Code zum Repository hinzuzufügen.</p> <pre><code>echo commit all changes git config user.email "&lt;E-Mail address of commit user"" git config user.name "Automatic Build" git checkout master git add --all git commit -m "$(CommitMessage)" echo push code to new repo git -c http.extraheader="AUTHORIZATION: bearer $(System.AccessToken)" push origin master </code></pre> <h3>Managed Solution erstellen</h3> <p>Nachdem die Solution aus der DEV-Umgebung extrahiert wurde, muss diese in die BULD/QA-Umgebung überführt und dort die Managed-Solution erstellt werden.</p> <p><img alt="Azure DevOps Pipeline Tasks" class="lb lb-img-noborder" lb-cust-margin="lb-cust-margin" noborder="yes" src="/2020/08/11/1/export-from-build.png" width="100%" /> <em>Abbildung: Azure DevOps Pipeline Tasks</em></p> <p>Für diesen Zweck werden im Kontext der Pipeline die beiden Tasks »Power Platform Import Solution« und »Power Platform Export Solution« verwendet. Bei letzterem Task ist es wichtig, dass die Option »Export as Managed Solution« aktiviert ist.</p> <p><img alt="Option »Export as Managed Solution«" class="lb lb-img-noborder" lb-cust-margin="lb-cust-margin" noborder="yes" src="/2020/08/11/1/export-from-build-managed.png" width="100%" /> <em>Abbildung: Option »Export as Managed Solution«</em></p> <p>Im letzten Schritt der Pipeline wird die exportierte Solution als Pipeline Artefakt veröffentlicht. Dieser Schritt ist wichtig, damit die erstellte Solution im Kontext des Releases dann nachgelagert in die Produktionsumgebung ausgerollt werden kann.</p> <h3>Deployment nach PROD</h3> <p>Mittels eines Release wird zuletzt die Solution Richtung »PROD« ausgerollt. Hierbei muss in den »Artifacts« zunächst das vorher erstellte Artefakt mit dem Release verknüpft werden.</p> <p><img alt="Release Pipeline - Artefakt Eigenschaften" class="lb lb-img-noborder" lb-cust-margin="lb-cust-margin" noborder="yes" src="/2020/08/11/1/deploy-to-prod.png" width="100%" /> <em>Abbildung: Release Pipeline - Artefakt Eigenschaften</em></p> <p>Über diesen Weg kann das Artefakt dann wiederum in den Tasks des Release verwendet werden. Wichtig ist, dass der »Alias« des Artefakts Bestandteil der Pfadangabe im Task für das eigentliche Deployment ist. Für diesen variablen Bestandteil steht keine Variable innerhalb von Azure DevOps zur Verfügung. Hintergrund dafür ist, dass in einem Release auch mehr als Artefakt verwendet werden kann und somit keine eindeutige Beziehung zwischen Variable und Artefakt möglich wäre.</p> <p><img alt="Release Pipeline - Artefakt-Alias" class="lb lb-img-noborder" lb-cust-margin="lb-cust-margin" noborder="yes" src="/2020/08/11/1/deploy-to-prod-alias.png" width="100%" /> <em>Abbildung: Release Pipeline - Artefakt-Alias</em></p> <h2>Tools</h2> <p>Wie zu Beginn erwähnt handelt es sich bei den Power Platform Build Tools im Grunde nur um einen Wrapper um das Tooling für Customer Engagement. Diese können wie in der folgenden Anleitung installiert und genutzt werden.</p> <p><a href="https://docs.microsoft.com/en-us/dynamics365/customerengagement/on-premises/developer/compress-extract-solution-file-solutionpackager">Use the SolutionPackager tool to compress and extract a solution file</a></p> <p>Im Anschluss sind alle Werkzeuge installiert, um die zuvor beschriebenen Schritte auch manuell lokal durchführen zu können. An dieser Stelle ist die Empfehlung aber, im Sinne der Zusammenarbeit lieber den ALM-Weg mittels Azure DevOps zu wählen.</p> <h2>Fazit</h2> <p>Unter Umständen ist ein Entwickler ein anderes Vorgehen gewohnt, wenn es um Versionierung von Quellcode geht. Die Entwicklung auf der Power Plattform bringt aber besondere Eigenheiten mit sich, wozu eben auch ein anderes Vorgehen bei diesem Prozess gehört.</p> <h2>Quellen</h2> <ol> <li><a href="https://docs.microsoft.com/en-us/power-platform/alm/">Application lifecycle management (ALM) with Microsoft Power Platform - Power Platform | Microsoft Docs</a></li> <li><a href="https://docs.microsoft.com/en-us/power-platform/alm/basics-alm">Application lifecycle management (ALM) basics with Microsoft Power Platform - Power Platform | Microsoft Docs</a></li> <li><a href="https://docs.microsoft.com/en-us/power-platform/alm/devops-build-tools#configure-service-connections-using-a-service-principal">Configure service connections using a service principal - Power Platform | Microsoft Docs</a></li> <li><a href="https://docs.microsoft.com/en-us/power-platform/admin/database-security">Configure user security in an environment - Power Platform | Microsoft Docs</a></li> <li><a href="https://docs.microsoft.com/en-us/powerapps/developer/common-data-service/use-single-tenant-server-server-authentication#azure-application-registration">Use Single-Tenant server-to-server authentication (Common Data Service) - Power Apps | Microsoft Docs</a></li> </ol> <p>[^1]: "There are two main paths you can use when working with solutions in a source control system:..." - <a href="https://docs.microsoft.com/en-us/power-platform/alm/alm-for-developers">ALM for developers - Power Platform | Microsoft Docs</a>, Abruf: 24.06.2020</p>https://andre.bering.in/de/posts/2020-08-11-application-lifecycle-management-alm-und-power-apps/Tue, 11 Aug 2020 10:00:00 +0000virtuelle Maschinen in Azure - Regionen und Kostenhttps://andre.bering.in/de/posts/2020-05-05-virtuelle-maschinen-in-azure-regionen-und-kosten/<p><img alt="D2v3 pro Tag" class="lb lb-img-noborder" noborder="yes" src="/2020/05/05/1/d2v3-pro-tag.png" width="100%" /></p> <p>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.</p> <!-- more --> <p>Nachfolgend wird davon ausgegangen, dass die virtuellen Maschinen nach dem sogenannten »Lift and Shift« Prinzip migriert werden. D.h. diese werden eins zu eins ohne Optimierung der jeweiligen Services nach Azure migriert. An dieser Stelle sei auch die Anmerkung erlaubt, dass dieses Vorgehen nicht zwangsläufig den besten Weg darstellt, sondern im Rahmen einer Migration in jedem Fall auch über Innovation von Services/Diensten nachgedacht werden muss.</p> <p><strong>Nachfolgend wird keine Empfehlung für eine generelle Umsetzung ausgesprochen. Dieser Ansatz soll lediglich dazu dienen belastbare Zahlen zu ermitteln, die im Rahmen einer Entscheidungsfindung genutzt werden können.</strong></p> <h2>Auswahl der VM-Typen</h2> <p>Microsoft fasst die zur Verfügung stehenden VM-Typen in verschiedenen Gruppen oder auch Serien zusammen (<a href="https://docs.microsoft.com/de-de/azure/virtual-machines/windows/sizes">Größen für virtuelle Windows-Computer in Azure</a>). Dies sind im Einzelnen:</p> <ul> <li><a href="https://docs.microsoft.com/de-de/azure/virtual-machines/sizes-general">Allgemeiner Zweck</a></li> <li><a href="https://docs.microsoft.com/de-de/azure/virtual-machines/sizes-compute">Computeoptimiert</a></li> <li><a href="https://docs.microsoft.com/de-de/azure/virtual-machines/sizes-memory">Arbeitsspeicheroptimiert</a></li> <li><a href="https://docs.microsoft.com/de-de/azure/virtual-machines/sizes-storage">Speicheroptimiert</a></li> <li><a href="https://docs.microsoft.com/de-de/azure/virtual-machines/sizes-gpu">GPU</a></li> <li><a href="https://docs.microsoft.com/de-de/azure/virtual-machines/sizes-hpc">High Performance Computing</a></li> </ul> <p>Die am häufigsten verwendeten Maschinen dürften »Allgemeiner Zweck« und »Arbeitsspeicheroptimiert« sein. Daher wird bei der weiteren Betrachtung in der Hauptsache auf diese beiden eingegangen. Da die deutschsprachigen Bezeichnungen m.M.n. etwas sperrig sind, werden im weiteren Verlauf die englischen Bezeichnungen »Memory optimized« (MO) und »General purpose« (GP) verwenden.</p> <h2>»Memory optimized« vs. »General purpose«</h2> <p>Der Hauptunterschied zwischen diesen Maschinentypen ist das Verhältnis von CPU und Arbeitsspeicher. Die jeweiligen Typen haben unterschiedliche Kostenstrukturen. Eine »<a href="https://docs.microsoft.com/en-us/azure/virtual-machines/dv3-dsv3-series">D2 v3</a>« Maschine hat bspw. ein Verhältnis von 1:4, also 4 GB RAM zu einer vCPU. Eine »<a href="https://docs.microsoft.com/en-us/azure/virtual-machines/ev3-esv3-series">E2 v3</a>« Maschine dahingegen weist ein Verhältnis von 1:8, also 8 GB RAM zu einer vCPU, auf.</p> <p>Bei genauerer Betrachtung der Kosten einer Serie, stellt man schnell fest, dass sich das Verhältnis von CPU/RAM sich nahezu parallel zum Preis entwickelt.</p> <p>Nachfolgend eine Visualisierung der Kosten für die D- und E-Serie.</p> <p><img alt="D-Serie Kosten" class="lb lb-img-noborder" noborder="yes" src="/2020/05/05/1/d-serie-kosten.png" width="100%" /></p> <p><img alt="E-Serie Kosten" class="lb lb-img-noborder" noborder="yes" src="/2020/05/05/1/e-serie-kosten.png" width="100%" /></p> <p>Die Grafiken wurden auf Basis der Stundenpreise erstellt, die am <strong>30.04.2020</strong> abgerufen wurden.</p> <h2>Azure Regionen</h2> <p>Wie man den oben stehenden Grafiken entnehmen kann, spielt auch die Auswahl der Azure Region auch bei der Kostenbetrachtung eine wichtige Rolle.</p> <p>In diesem Fall wurden die Regionen »West Europe« (WE) und »Germany North (Public)« (GN) gegenübergestellt.</p> <p>Schaut man sich hier bspw. die größte verfügbare Maschine der D-Serie an, so beträgt der Preisunterschied zwischen WE und GN <strong>19,11€ pro Tag</strong> zu Gunsten von WE. In einem Monat ergibt sich so eine Differenz von fast <strong>600€</strong>.</p> <h2>Auswahl der richtigen Größe</h2> <p>Noch wichtiger bei der Auswahl einer VM ist aber die Wahl der richtigen Größe. Hierbei sollte das Augenmerk vor allen Dingen auf die Auslastung der Maschinen gelegt werden. Idealerweise sollte eine Maschine &gt; 50% und im besten Fall &gt; 80% ausgelastet sein. Liegt die Auslastung unter 50% sollte der Wechsel auf die nächstkleinere Größe in Erwägung gezogen werden.</p> <p>Wechselt man bspw. in der Region WE von »D8 v3« auf »D4 v3« spart man 50% der Kosten pro Tag. Konkret 17,16€ zu 8,58€. Hieran wird deutlich, dass das größte Einsparungspotenzial bei der Wahl der passenden Maschinengröße vorhanden ist.</p> <h2>Fazit</h2> <p>Es kann Gründe für die Wahl einer spezifischen Azure Region geben, bspw. Compliance. Bei der Auswahl sollten aber auch immer die Kosten berücksichtigt werden, da hier großes Einsparungspotenzial vorhanden ist, das nicht immer auf den ersten Blick ersichtlich ist.</p> <p>Noch wichtiger ist es aber die Auslastung der Maschinen im Blick zu halten. Hier sollte eine Auslastung &gt; 50% erreicht sein und sonst der dynamische Wechsel auf eine kleinere Maschine erfolgen.</p> <p>[^direkt]: Kosten die einem Asset oder Service direkt zugeordnet werden können. Anschaffungskosten sind ein gutes Beispiel hierfür. [^indirekt]: Verwaltungskosten sind ein gutes Beispiel für indirekte Kosten. Hierzu zählen bspw. auch Kosten für die Sicherheit des Rechenzentrums oder das Barcode-Etikett, welches an einem bestimmten Server angebracht ist.</p>https://andre.bering.in/de/posts/2020-05-05-virtuelle-maschinen-in-azure-regionen-und-kosten/Tue, 05 May 2020 08:30:00 +0000Umbenennen der Azure "Root Management Group" nicht möglichhttps://andre.bering.in/de/posts/2020-04-07-umbenennen-der-azure-root-management-group-nicht-m%C3%B6glich/<p>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 <a href="https://docs.microsoft.com/en-us/azure/governance/management-groups/overview#root-management-group-for-each-directory">"Root" management group</a> umbenennen möchte. Aber schon die einfache Abfrage der Gruppe wird zu einem Problem führen.</p> <p><img alt="Management Group query error" class="lb lb-img-noborder" noborder="yes" src="/2020/04/07/1/mg-query-error.png" width="100%" /></p> <p>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.</p> <p><img alt="Azure Portal hint" class="lb lb-img-noborder" noborder="yes" src="/2020/04/07/1/azure-portal-hint.png" width="100%" /></p> <p>Das gesamte Vorgehen hierfür ist im Artikel »<a href="https://docs.microsoft.com/de-de/azure/role-based-access-control/elevate-access-global-admin">Erhöhen der Zugriffsrechte zum Verwalten aller Azure-Abonnements und Verwaltungsgruppen</a>« 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.</p> <p><img alt="Management Group query success" class="lb lb-img-noborder" noborder="yes" src="/2020/04/07/1/mg-query-success.png" width="100%" /></p> <p>{{&lt; warning &gt;}} Nachdem man die notwendigen Änderungen mit den erhöhten Zugriffsrechten durchgeführt hat, sollte man die Zugriffsrechte im Nachgang wieder herabsetzen. {{&lt; /warning &gt;}}</p> <p>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.</p> <pre><code>az account management-group list </code></pre> <p><img alt="List Management Group" class="lb lb-img-noborder" noborder="yes" src="/2020/04/07/1/list-mg.png" width="100%" /></p>https://andre.bering.in/de/posts/2020-04-07-umbenennen-der-azure-root-management-group-nicht-m%C3%B6glich/Tue, 07 Apr 2020 10:00:00 +0000Azure Function in Docker Container ausführenhttps://andre.bering.in/de/posts/2020-02-21-azure-function-in-docker-container-ausf%C3%BChren/<h2>Einleitung</h2> <p>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 (<a href="https://twitter.com/jeffhollan/status/1230705929051492352">Ausgabe 20.02.2020</a>) 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.</p> <p>Daher zeigt dieser Artikel wie man Azure Functions mit einem Http Trigger Docker betreiben kann.</p> <!-- more --> <h2>Voraussetzungen</h2> <ul> <li><a href="https://docs.microsoft.com/de-de/azure/azure-functions/functions-run-local">Azure Functions Core Tools</a> &gt;= 2.7.2184 und &lt; 3.0</li> <li>Windows</li> <li>Docker</li> </ul> <p>Dieser Artikel bezieht sich auf das Vorgehen unter Windows. Unter MacOS sollte das Vorgehen auch so funktionieren lediglich spezifische Befehle wie bspw. das Anlegen von Verzeichnissen muss angepasst werden.</p> <h2>Azure Function erzeugen</h2> <p>Um ein neues Azure Function Projekt mit einem Http Trigger und Dockerfile zu erzeugen, können einfach die folgenden Befehle ausgeführt werden. Als Runtime bei der Erzeugung wählen wir <code>dotnet</code> aus.</p> <pre><code>mkdir funcDemoDocker cd funcDemoDocker func init func new --name MyHttpTrigger --template "HttpTrigger" func init --docker-only </code></pre> <p>Im Anschluss kann das Projekt auch direkt gestartet werden und so die Azure Function in der CLI ausgeführt werden.</p> <pre><code>func start --build </code></pre> <p>Danach kann man wie gewohnt die Azure Function im Browser aufrufen.</p> <p><img alt="Function local" class="lb lb-img-noborder" noborder="yes" src="/2020/02/19/1/function-local.png" width="100%" /></p> <p>Im Projekt befindet sich auch das passende Dockerfile zum erzeugen des notwendigen Docker-Images.</p> <pre><code>docker build -t funcdemodocker . </code></pre> <p>Nachdem das Image erzeugt ist, können wir einen Container starten.</p> <pre><code>docker run -p 8080:80 funcdemodocker </code></pre> <p>Ruft man nun die Verwaltungsseite der Azure Function auf, sieht man, dass diese ganz normal gestartet ist.</p> <p><img alt="Function Docker local" class="lb lb-img-noborder" noborder="yes" src="/2020/02/19/1/function-docker-local.png" width="100%" /></p> <p>Versucht man dann allerdings den Http Trigger anzusprechen, erhält man einen 401 (Unauthorized) Fehler.</p> <p><img alt="Function Docker local 401" class="lb lb-img-noborder" noborder="yes" src="/2020/02/19/1/function-docker-local-401.png" width="100%" /></p> <p>Die Ursache hierfür ist, dass beim lokalen Ausführen mittels der CLI die Authentisierung der Azure Function deaktiviert wird. Dies ist bei der Ausführung in Docker nicht der Fall.</p> <h2>Lösung</h2> <p>Um dieses Problem zu lösen, muss man nur die Keys definieren und mittels Parametern dem Container oder genauer der Azure Function Runtime mitteilen, wo diese zu finden sind. Dazu muss zunächst die Datei mit den Keys erzeugt werden. In diesem Fall wird diese Datei im Verzeichnis <code>C:\dev\my-secrets</code> mit dem Namen <code>host.json</code> angelegt. Der Inhalt der Datei sollte wie folgt aussehen:</p> <pre><code>{ "masterKey": { "name": "master", "value": "&lt;key&gt;", "encrypted": false }, "functionKeys": [{ "name": "default", "value": "&lt;key&gt;", "encrypted": false }] } </code></pre> <p>Der <code>&lt;key&gt;</code> kann durch einen beliebigen Wert, für Tests bspw. <code>test1234</code>, ersetzt werden. Um den Container dann zu starten, wird der folgende Befehl ausgeführt.</p> <pre><code>docker run -v C:\dev\my-secrets:/azure-functions-host/Secrets -e AzureWebJobsSecretStorageType=files -p 8080:80 funcdemodocker </code></pre> <p>Im Anschluss kann man wie gewohnt den Http Trigger unter Nutzung des Keys ansprechen.</p> <p><img alt="Function Docker local success" class="lb lb-img-noborder" noborder="yes" src="/2020/02/19/1/function-docker-local-success.png" width="100%" /></p> <h2>Fazit</h2> <p>Mittels des oben beschriebenen Wegs kann man auch Azure Functions mit Http Trigger in einem Docker Container betreiben. Das dabei auftretende Problem der nicht bekannten Keys wird über das explizite setzen dieser gelöst. Wie oben erwähnt soll dieser Workaround in der nächsten Version der Azure Functions Core Tools behoben sein und die Schlüssel automatisch erzeugt und beim Start angezeigt werden.</p>https://andre.bering.in/de/posts/2020-02-21-azure-function-in-docker-container-ausf%C3%BChren/Fri, 21 Feb 2020 19:20:00 +0000Umbau für "DE"-Inhaltehttps://andre.bering.in/de/posts/2019-12-08-umbau-f%C3%BCr-de-inhalte/<p>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.</p> <p>Daher gibt es jetzt auch die "/de" URL.</p> <p>Die Newsfeeds sind beide getrennt verfügbar. Falls jemand Interesse an Inhalten beider Sprachen hat, müssen auch beide RSS-Feeds abonniert werden.</p>https://andre.bering.in/de/posts/2019-12-08-umbau-f%C3%BCr-de-inhalte/Sun, 08 Dec 2019 19:15:00 +0000