Findings and thingies - Articleshttps://andre.bering.in/articles-feed http://www.rssboard.org/rss-specificationWed, 27 Jan 2021 00:40:21 +0000Back to custom CMShttps://andre.bering.in/2021/01/12/2/<p>As you might have noticed I haven't published anything since the last <a href="/posts/2020-09-14-back-to-wordpress">entry</a> where I mentioned that I switched back to WordPress.</p> <p>Being a technical person I really don't like the experience of putting content into WordPress. Meanwhile I've been trying to get around this by faciliating the <code>wp cli</code> which didn't work out very well for me.</p> <p>Therefore I decided to get back on track to create a custom CMS. This time in Python. For storing content I followed an approach which I was inspired by <a href="https://aaronparecki.com/">Aaron Pericki</a>.</p> <p>Moreover I looked into <a href="https://indieweb.org/">IndieWeb</a> and therefore I decided to split content into different types like notes, articles and bookmarks. <strong>Due to this the feed structure of this site will change a little bit. You can find all details for feeds <a href="/feeds/">here</a>.</strong></p> <p>If nothing is changed in the Feed Reader, all content will show up in this default feed (<a href="/feed">/feed</a>) in the future.</p>https://andre.bering.in/2021/01/12/2/Tue, 12 Jan 2021 12:00:00 +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 +0000Back to Wordpresshttps://andre.bering.in/posts/2020-09-14-back-to-wordpress/<p>After I switched to Hugo as the generator for this page before some time ago, I often asked myself if a comment function could lead to a higher degree of interaction. Of course, this question is difficult or even impossible to answer afterwards. Anyway, the page is now run by WordPress again.</p> <p>All URL patterns used so far should still work. If not, please leave a comment.</p>https://andre.bering.in/posts/2020-09-14-back-to-wordpress/Mon, 14 Sep 2020 12:53:21 +0000Application Lifecycle Management (ALM) and Power Appshttps://andre.bering.in/posts/2020-08-12-application-lifecycle-management-alm-and-power-apps/<h2>Introduction</h2> <p>This article will explain how to apply Application Lifecycle Management (ALM) in Azure DevOps for Power Apps. It will be shown how to set up the required Azure DevOps environment. Furthermore, it will be described how source code/Power Apps can be versioned, quality assurance can be performed and subsequently artifacts delivered to the production environment.</p> <p>The history of the article is longer. The first draft was already written by me in 2019. In the meantime I have worked on it again and again. What finally kept me from publishing it was, in my opinion, not yet "<strong>finished</strong>" tooling of the "<a href="https://docs.microsoft.com/en-us/power-platform/alm/devops-build-tools">Microsoft Power Platform Build Tools for Azure DevOps - Power Platform | Microsoft Docs</a>". The originally available tooling (Azure DevOps Extension) is still available now but has been marked as "DEPRECATED" since the jump to version 0.3.7. Already since the jump from version 0.1.16 to version 0.3.6 the original tooling has been fundamentally revised/improved. </p> <p>In version 0.1.16, the access credentials (user name/password) had to be stored in plain text to set up the connection. Since version 0.3.6 this authentication can finally be setup using <a href="https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals">Service Principals</a>.</p> <p><img alt="Authentication methods" class="lb lb-img-noborder" lb-cust-margin="lb-cust-margin" noborder="yes" src="/2020/08/12/1/devops-principal.png" width="100%" /> <em>Figure: Authentication methods</em></p> <p>The old (<strong><ins>not recommended</ins></strong>) method (yellow) is still available. So the transition to the new option (green) is seamless, even for users who have already used previous versions of BuildTools or have not yet set up Service Principals. <strong>When changing to or starting with the current version of the Build Tools, you should always be using Service Principals</strong>.</p> <p>Two versions are available in the Visual Studio Marketplace: 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>As described above, this extension [2] is now marked as "<strong>DEPRECATED</strong>", so only [1] should be used.<br /> The tools currently available for Azure DevOps are basically a wrapper around the SolutionPackager for D365 Customer Engagement (CRM).</p> <p>The final architecture, for the integration of Azure DevOps and Power Platform, will look like the following on an abstract level.</p> <p><img alt="Architecture overview" class="lb lb-img-noborder" lb-cust-margin="lb-cust-margin" noborder="yes" src="/2020/08/12/1/architecture.png" width="100%" /> <em>Figure: Architecture overview</em></p> <p>Microsoft itself suggests two different approaches for ALM in conjunction with the Power Platform. [^1] In this article the first variant is described, where only the source code is versioned, but not the packed solutions. In the context of classical software development this is also the <em>normal</em> way, because usually only source code and not compiled binaries are versioned.</p> <!-- more --> <h2>Requirements</h2> <p>Basically, a few things are needed to be able to follow the steps. The following components are required.</p> <ul> <li>3 Power Apps Environments (e.g. <a href="https://docs.microsoft.com/en-us/office/developer-program/office-365-developer-program-get-started">Microsoft 365-Entwicklerabonnements</a> with three accounts inside the tenant each connected to <a href="https://powerapps.microsoft.com/en-us/communityplan/">Power Apps-Communityplan</a>)</li> <li>1 Azure DevOps project</li> <li>installed <a href="https://docs.microsoft.com/en-us/power-platform/alm/devops-build-tools">Microsoft Power Platform Build Tools for Azure DevOps - Power Platform | Microsoft Docs</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"> If a Microsoft 365 developer subscription is used, it must be clear that it expires after 90 days if no M365 development has been performed. For the extension it is sufficient that, for example, a <a href="https://docs.microsoft.com/en-us/sharepoint/dev/spfx/web-parts/get-started/build-a-hello-world-web-part">SharePoint Web Part</a> is created/developed. </div> </aside> <h2 id="getting-started">Getting started</h2> <p>As mentioned above, three environments are required to follow this guide. For the following steps the following environments with the corresponding definitions are used.</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>As you can see, these three environments are visible in the <a href="http://aka.ms/ppac">Power Platform Admin Center</a>.</p> <p><img alt="Environment overview" class="lb lb-img-noborder" lb-cust-margin="lb-cust-margin" noborder="yes" src="/2020/08/12/1/environment-overview.png" width="100%" /> <em>Figure: Environment overview</em></p> <p>Having a background as a developer, the first question that might arise is how to version control your work in the Power Platform. At the moment there is no easy way to do this. The only way is to manually download the solution, unzip it and then version the content.</p> <p>This process can be mapped into Azure DevOps using ALM, even with a kind of CI/CD approach.<br /> The article is mainly based on the Microsoft tutorial for the Power Apps Build Tools, which can be found <a href="https://github.com/microsoft/PowerApps-Samples/tree/master/build-tools">here</a>.</p> <p>For the tutorial and the further steps the URL of the respective environment is required. The URL can be found in the <a href="https://aka.ms/ppac">Admin Center</a>.</p> <p><img alt="Admin Center - Environment URL" class="lb lb-img-noborder" lb-cust-margin="lb-cust-margin" noborder="yes" src="/2020/08/12/1/environment-url.png" width="100%" /> <em>Figure: Admin Center - Environment URL</em></p> <p>If any form of ALM is to be used with Power Apps, it is first necessary to understand how solutions work in this context. To understand these basics you can read this Microsoft Docs article: <a href="https://docs.microsoft.com/en-us/powerapps/maker/common-data-service/solutions-overview">Solutions in Power Apps - Power Apps | Microsoft Docs</a></p> <p>In this article there is another introduction linked, which should be read: <a href="https://docs.microsoft.com/en-us/powerapps/developer/common-data-service/introduction-solutions">Introduction to solutions - Power Apps | Microsoft Docs</a></p> <h2 id="service-principal">Service connections / Service Principals</h2> <p>To be able to set up the connection in Azure DevOps, the corresponding Service Principal must be set up or stored in Azure DevOps. The corresponding menu item is located below "<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/12/1/create-new-sc.png" width="100%" /> <em>Figure: Azure DevOps Service - Create new service connection</em></p> <p><img alt="Azure DevOps Service connections" class="lb lb-img-noborder" lb-cust-margin="lb-cust-margin" noborder="yes" src="/2020/08/12/1/create-serviceconnection.png" width="100%" /> <em>Figure: Azure DevOps Service connections</em></p> <p>In the dialogue, reference is made to two places which should help to create the corresponding access or to store it in the correct place. The first link refers to instructions in Microsoft Docs. There it is recommended to create the access using a linked PowerShell script. However, the script can only be executed under Windows because the PowerShell modules used require "System.Forms" and these are only available under Windows. Therefore I recommend that the Service Principal is created directly in the Azure Portal. The corresponding documentation is linked in the continuous text of the manual.</p> <aside class="article-alert article-alert-warning"> <div class="alert-warning-icon"> <img src="/img/exclamation.svg" /> </div> <div class="alert-warning-content"> The Service Principal must be created in the Tenant in which the Power Apps environments are located. </div> </aside> <p><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></p> <p>After the Service Principal(s) have been created in Azure in, the setup can be continued.</p> <p>The crucial point is that there is <strong>not</strong> the item "<strong>Settings</strong>" as in the manual, but the item "<strong>Advanced Settings</strong>". This item can be used to call up the corresponding interface. </p> <p><img alt="Settings - Advanced Settings" class="lb lb-img-noborder" lb-cust-margin="lb-cust-margin" noborder="yes" src="/2020/08/12/1/01-create-sp.png" width="100%" /> <em>Figure: Settings - Advanced Settings</em></p> <p>At this point, you might be surprised when the Dynamics 365 interface appears. The two platforms are very closely intertwined, so that certain settings are currently only (still) found in the <em>old</em> interface. The changeover to an end-to-end management interface is an ongoing process. Therefore it can be assumed that in the future the points will also be integrated into the power platform interface or a uniform look and feel.</p> <p>There is another stumbling block in the Microsoft documentation, namely the creation of the user. However, the behavior regarding this stumbling block was not consistent.<br /> For this reason, the following are the individual dialogs that must be processed to make the Service Principal known within the power platform environment. </p> <p><img alt="D365 Settings" class="lb lb-img-noborder" lb-cust-margin="lb-cust-margin" noborder="yes" src="/2020/08/12/1/02-create-sp.png" width="100%" /> <em>Figure: 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/12/1/03-create-sp.png" width="100%" /> <em>Figure: D365 Security</em></p> <p>In the user list view, filter to "Application Users" and then click "+ NEW".</p> <p><img alt="Filter user list" class="lb lb-img-noborder" lb-cust-margin="lb-cust-margin" noborder="yes" src="/2020/08/12/1/04-create-sp.png" width="100%" /> <em>Figure: Filter user list</em></p> <p>Before entering the data, the dialog must be switched to the correct mode by selecting "Application User".</p> <p><img alt="Select 'Application User'" class="lb lb-img-noborder" lb-cust-margin="lb-cust-margin" noborder="yes" src="/2020/08/12/1/05-create-sp.png" width="100%" /> <em>Figure: Select 'Application User'</em></p> <p>When entering the data, the information that was previously defined when the Service Principal was created in the Azure Portal must be used. The user also needs (because it is a mandatory field of the form) an e-mail address, even if it is only a technical user account. Here, for example, addresses of so-called example domains (<a href="https://de.wikipedia.org/wiki/Beispieldomains">example domains - Wikipedia</a>) can be used, as can be seen in the following screenshot However, the address is not used for sending e-mails.<br /> After creating the user by clicking the "SAVE" button, do not close the <strong>not</strong> dialog.</p> <p><img alt="Enter user information" class="lb lb-img-noborder" lb-cust-margin="lb-cust-margin" noborder="yes" src="/2020/08/12/1/06-create-sp.png" width="100%" /> <em>Figure: Enter user information</em></p> <p>Using the button "MANAGE ROLES" the necessary role must be assigned to the user account.</p> <p><img alt="Open 'MANAGE ROLES'" class="lb lb-img-noborder" lb-cust-margin="lb-cust-margin" noborder="yes" src="/2020/08/12/1/07-create-sp.png" width="100%" /> <em>Figure: Open 'MANAGE ROLES'</em></p> <p>To be able to perform all necessary actions with this user account, the role "System Administrator" must be assigned. Otherwise, errors will occur later in the context of using this accountby the Azure DevOps Pipelines.</p> <p><img alt="User role selection" class="lb lb-img-noborder" lb-cust-margin="lb-cust-margin" noborder="yes" src="/2020/08/12/1/08-create-sp.png" width="100%" /> <em>Figure: User role selection</em></p> <p>After this step the account is set up and can now be stored in Azure DevOps. For this purpose the dialog which is shown/described at the beginning of this section ("<a href="{{&lt; ref" title="#service-principal&quot; &gt;}})">Service connections / Service Principals</a> must be used.</p> <p>An individual Service Connection must be created for each power platform environment. In total, the setup described above must be carried out three times, whereby the Service Principal does not have to be created three times. The Service Principal can be stored as a user account in each environment.<br /> Alternatively, a separate Service Principal can be created for each environment.</p> <p><img alt="Azure DevOps Service connections list" class="lb lb-img-noborder" lb-cust-margin="lb-cust-margin" noborder="yes" src="/2020/08/12/1/devops-service-connections-list.png" width="100%" /> <em>Figure: Azure DevOps Service connections list</em></p> <p>Then create all required connections with the respective information/access data per environment.</p> <p><img alt="Azure DevOps Service connection properties" class="lb lb-img-noborder" lb-cust-margin="lb-cust-margin" noborder="yes" src="/2020/08/12/1/devops-service-connections-properties.png" width="50%" /> <em>Figure: Azure DevOps Service connection properties</em></p> <p>As described in the section "<a href="{{&lt; ref &quot;#getting-started&quot; &gt;}}">Getting Started</a>", the URL of the environment is required and this value is stored as "<em><strong>Server URL</strong></em>" in Service Connection properties.</p> <h2>Azure DevOps Pipelines</h2> <h3>Introduction</h3> <p>Once the Service Connections have been created, the pipelines and releases must now be set up. These are used to extract the source code from "DEV", create a Managed Solution in "QA/Build" and then roll out this Solution in "PROD".</p> <p>One pipeline is required for each of the first two steps.</p> <p><img alt="Azure DevOps Pipelines list" class="lb lb-img-noborder" lb-cust-margin="lb-cust-margin" noborder="yes" src="/2020/08/12/1/pipelines-list.png" width="100%" /> <em>Figure: Azure DevOps Pipelines list</em></p> <p>An Azure DevOps release is then used for the final deployment towards PROD.</p> <p><img alt="Azure DevOps Releases list" class="lb lb-img-noborder" lb-cust-margin="lb-cust-margin" noborder="yes" src="/2020/08/12/1/releases-list.png" width="100%" /> <em>Figure: Azure DevOps Releases list</em></p> <h3>Repository permissions</h3> <p>Below "<em><strong>Project Settings - Repos - Repositories User</strong></em>" the account "<em><strong>\&lt;Azure DevOps Project Name> Build service (\&lt;Organization name>)</strong></em>" must be granted the "<em><strong>Contribute</strong></em>" permission. Otherwise, the build pipeline cannot push the source code into the repository.</p> <p><img alt="'Build Service' permissions" class="lb lb-img-noborder" lb-cust-margin="lb-cust-margin" noborder="yes" src="/2020/08/12/1/build-service-permission.png" width="100%" /> <em>Figure: 'Build Service' permissions</em></p> <h3>Solution export</h3> <p>There are four steps in the pipeline for exporting the solution and one more for adding the code to the repository.</p> <p><img alt="Azure DevOps pipeline tasks" class="lb lb-img-noborder" lb-cust-margin="lb-cust-margin" noborder="yes" src="/2020/08/12/1/export-from-dev.png" width="100%" /> <em>Figure: Azure DevOps pipeline tasks</em></p> <p>To add the source code to the repository, a few command-line commands are required to have Git run automatically in the context of the pipeline.</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/12/1/task-add-source-code.png" width="100%" /> <em>Figure: Azure DevOps pipeline command line task</em></p> <p>The variable should be emphasized here. This must / can be set when the queue is started. This means that the respective commit comment can always be set dynamically during the respective run. The code for this task can be found in the following section.</p> <h4>Source code in repository</h4> <p>The commands are used in the final step "Commit solution to repo" to add the code to the repository.</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>Create managed solution</h3> <p>After the solution has been extracted from the DEV environment, it must be transferred to the BULD/QA environment where the managed solution is created.</p> <p><img alt="Azure DevOps pipeline tasks" class="lb lb-img-noborder" lb-cust-margin="lb-cust-margin" noborder="yes" src="/2020/08/12/1/export-from-build.png" width="100%" /> <em>Figure: Azure DevOps pipeline tasks</em></p> <p>For this purpose, the two tasks "Power Platform Import Solution" and "Power Platform Export Solution" are used in the context of the pipeline. For the latter task it is important that the option "Export as Managed Solution" is activated.</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/12/1/export-from-build-managed.png" width="100%" /> <em>Figure: Option »Export as Managed Solution«</em></p> <p>In the last step of the pipeline, the exported solution is published as pipeline artifact. This step is important so that the solution created in the context of the release can then be rolled out in the production environment.</p> <h3>Deployment to PROD</h3> <p>With a release, the solution is rolled out into the "PROD" environment. In this case, the artifact previously created must first be linked to the Release in the "Artifacts".</p> <p><img alt="Release pipeline - artifact properties" class="lb lb-img-noborder" lb-cust-margin="lb-cust-margin" noborder="yes" src="/2020/08/12/1/deploy-to-prod.png" width="100%" /> <em>Figure: Release pipeline - artifact properties</em></p> <p>This way the artifact can be used in the tasks of the release. It is important that the "alias" of the artifact is part of the path specification in the task for the actual deployment. There is no variable within Azure DevOps for this variable part. The reason for this is that more than one artifact can be used in a release and therefore a unique relationship between variable and artifact would not be possible.</p> <p><img alt="Release Pipeline - artifact alias" class="lb lb-img-noborder" lb-cust-margin="lb-cust-margin" noborder="yes" src="/2020/08/12/1/deploy-to-prod-alias.png" width="100%" /> <em>Figure: Release Pipeline - artifact alias</em></p> <h2>Tools</h2> <p>As mentioned in the beginning, the Power Platform Build Tools are basically just a wrapper around the tooling for customer engagement. They can be installed and used as in the following instructions.</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>Afterwards, all tools are installed in order to be able to perform the previously described steps manually locally. At this point, however, it is recommended to choose the ALM path using Azure DevOps for the sake of cooperation.</p> <h2>Conclusion</h2> <p>A developer may be used to a different approach when it comes to versioning source code. However, development on the Power Platform brings with it special peculiarities, which include a different approach to this process.</p> <h2>Sources</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>, Retrieval: 24.06.2020</p>https://andre.bering.in/posts/2020-08-12-application-lifecycle-management-alm-and-power-apps/Wed, 12 Aug 2020 11: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 +0000Weekly CW17-2020https://andre.bering.in/posts/2020-04-24-weekly-cw17-2020/<p><img alt="Weekly CW17" class="lb lb-img-noborder" noborder="yes" src="/2020/04/24/1/weekly-cw17.svg" width="100%" /></p> <p>When you try to focus on one technology, such as Microsoft Azure, as I do, you often forget to think outside the box. Due to the current situation, Google has made all online training materials for the Google Cloud currently available for 30 days free of charge.</p> <p><a href="https://cloud.google.com/blog/topics/training-certifications/expanding-at-home-learning">Google Cloud learning resources at no cost for 30 days | Google Cloud Blog</a></p> <p>Really a good possibility to extend your own knowledge and to look beyond your own nose, if you have not had any contact with GCP before.</p> <p>If you have had contact with databases as a developer, ask why things are the way they are and what needs to be considered to prevent problems. »<a href="https://medium.com/@rakyll/things-i-wished-more-developers-knew-about-databases-2d0178464f78">Things I Wished More Developers Knew About Databases</a>« is a longer article, but a really good one.</p> <p>There are several ways to get started using Microsoft Graph. One possible good one is »<a href="https://developer.microsoft.com/en-us/graph/blogs/a-lap-around-microsoft-graph-toolkit-in-day-1-an-overview-of-microsoft-graph-toolkit/">A Lap around Microsoft Graph Toolkit in Day 1 - An Overview of Microsoft Graph Toolkit</a>«.</p> <p>Developers who are starting to get involved with Power Apps are often surprised that OOTB there are no popup dialogs in Power Apps. But not everyone needs to reinvent the wheel. Therefore you should use components that have already been developed by others. »<a href="https://powerusers.microsoft.com/t5/Canvas-Apps-Components-Samples/Canvas-Power-App-Modal-Dialog-Popup/td-p/525015">Canvas Power App Modal Dialog (Popup) - Power Platform Community</a>« shows one possible way.</p> <!--more-->https://andre.bering.in/posts/2020-04-24-weekly-cw17-2020/Fri, 24 Apr 2020 07:00:00 +0000Weekly CW16-2020https://andre.bering.in/posts/2020-04-17-weekly-cw016-2020/<p><img alt="Weekly CW16" class="lb lb-img-noborder" noborder="yes" src="/2020/04/17/1/weekly-cw16.svg" width="100%" /></p> <p>Julie Lerman wrote a very detailed article about the Entity Framework Core 3.0 with »<a href="https://www.codemag.com/article/1911062">Entity Framework Core 3.0: A Foundation for the Future</a>«. Very interesting to read why the Entity Framework team has laid the foundation for further innovations with this version.</p> <p>Uncertain which asynchronous messaging solution in Azure is the right one for a specific requirement? Then you should read the documentation »<a href="https://docs.microsoft.com/en-us/azure/architecture/guide/technology-choices/messaging">Asynchronous messaging options in Azure</a>« from Microsoft to get a good overview of all available options.</p> <p>If you want to start running an ASP.NET Core application in a container then you will often have basic questions about how to start it. <a href="https://www.linkedin.com/in/greg-roe-3a7b66b/">Greg Roe</a> has published a two-part article that explains exactly that. * »<a href="https://devblogs.microsoft.com/premier-developer/hosting-and-asp-net-core-api-in-a-container-part-1-of-2-building-the-container/">Hosting and ASP.NET Core API in a Container Part 1 of 2 - Building the Container</a>« * »<a href="https://devblogs.microsoft.com/premier-developer/push-an-asp-net-core-api-container-to-azure-containter-registry-part-2-of-2/">Push to ASP.NET Core API Container to Azure Container Registry Part 2 of 2</a>«</p>https://andre.bering.in/posts/2020-04-17-weekly-cw016-2020/Fri, 17 Apr 2020 07:00:00 +0000Weekly CW015-2020https://andre.bering.in/posts/2020-04-10-weekly-cw015-2020/<p><img alt="Weekly CW15" class="lb lb-img-noborder" noborder="yes" src="/2020/04/10/1/weekly-cw15.svg" width="100%" /></p> <p>Personally the biggest announcement this week was that Microsoft <a href="https://www.theverge.com/2020/4/7/21211721/microsoft-events-build-2021-digital-only-coronavirus-plans">announced</a> that all of their events will be digital-only until July 2021. For me personally this could be an indicator on when we could expect things to become normal again after the current pandemic.</p> <p>Are you interested in IoT and looking to get a »<a href="https://docs.microsoft.com/en-us/learn/certifications/exams/az-220">AZ-220: Azure #MSIoT Developer certification</a>«? Then you can get start your preparation with »<a href="https://docs.microsoft.com/en-us/learn/modules/set-up-iot-edge-gateway/">Set up an IoT Edge Gateway</a>«.</p> <p>If you ever wondered on how to create a solution using CQRS and Event Sourcing using C# then you definitely should have a look at »<a href="https://www.codeproject.com/Articles/5264244/A-Fast-and-Lightweight-Solution-for-CQRS-and-Event">A Fast and Lightweight Solution for CQRS and Event Sourcing</a>«. A very comprehensive article which explains this end-to-end.</p> <p>Are you a SharePoint or Teams developer and ever asked yourself why you should care about Azure Functions? Then you should have a look at »<a href="https://developer.microsoft.com/en-us/microsoft-365/blogs/microsoft-365-sharepoint-pnp-weekly-episode-74/">Microsoft 365 &amp; SharePoint PnP Weekly – Episode 74</a>«.</p>https://andre.bering.in/posts/2020-04-10-weekly-cw015-2020/Fri, 10 Apr 2020 10:00:00 +0000Renaming Azure "Root" management group not possiblehttps://andre.bering.in/posts/2020-04-07-renaming-azure-root-management-group-not-possible/<p>When you start dealing with management groups in Azure, you may get to the point where you want to rename the <a href="https://docs.microsoft.com/en-us/azure/governance/management-groups/overview#root-management-group-for-each-directory">"Root" management group</a>. But even the simple query of the group will cause a problem.</p> <p><img alt="Management Group query error" class="lb lb-img-noborder" noborder="yes" src="/2020/04/07/2/mg-query-error.png" width="100%" /></p> <p>In order for modifications/queries to be possible for this management group, you must first elevate the access rights for your own account, even if you are already a directory administrator. A corresponding message is also displayed in the Azure Portal.</p> <p><img alt="Azure Portal hint" class="lb lb-img-noborder" noborder="yes" src="/2020/04/07/2/azure-portal-hint.png" width="100%" /></p> <p>The entire process is explained in the article "<a href="https://docs.microsoft.com/en-us/azure/role-based-access-control/elevate-access-global-admin">Elevate access to manage all Azure subscriptions and management Groups</a>". Once you have altered your own access rights as described here or had them altered, you can make the appropriate changes or simply query the management group.</p> <p><img alt="Management Group query success" class="lb lb-img-noborder" noborder="yes" src="/2020/04/07/2/mg-query-success.png" width="100%" /></p> <p>{{&lt; warning &gt;}} After you have made the necessary changes with the elevated access rights, you should remove the access rights afterwards. {{&lt; /warning &gt;}}</p> <p>Unfortunately, the "Tenant Root Group" cannot be queried by name in the Azure CLI resp. the name of this group is not meaningful. However, with elevated access rights you can query all management groups and thus find out the name of this particular group.</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/2/list-mg.png" width="100%" /></p>https://andre.bering.in/posts/2020-04-07-renaming-azure-root-management-group-not-possible/Tue, 07 Apr 2020 10:00:00 +0000