Auch der zweite Tag auf der Microsoft Build 2020 brachte für busitec-CEO Henning Eiben spannende und neue Erkenntnisse. Hier hat er die wichtigsten Inhalte seiner besuchten Sessions zusammengefasst.
Mein persönliches Highlight waren die neuen Features rund um ARM Templates. Da wir in der letzten Zeit sehr viele, umfangreiche ARM Deployments durchgeführt haben, freue ich mich auf diese vorgestellten Veränderungen.
DevOps-Arbeitsbereiche in Microsoft Teams erstellen
In der Session ging es darum zu zeigen, wie man Microsoft Teams in typischen DevOps-Prozessen verwenden kann. Teams kommt dabei in der sogenannten „inner-loop“ des (DevOps-)Teams (hier als Teams=Mitglieder) zum Einsatz. Im Kern wurde ein Setup vorgestellt mit einem Team pro Produkt beziehungsweise Projekt und eine ganze Reihe von Channels. Wenn man als Teams und Channels einmal für DevOps-Teams organisiert, dann kann man das wie folgt mappen:
Wenn man sich dann einmal ein Team ansieht, könnte das so aussehen:
Channels leben also davon, dass man sie mit Hilfe von Apps und Bots erweitert und somit gezielte Informationen in die jeweiligen Channels bereitstellt.
Referenz: Create DevOps workspaces in Teams
Infrastructure as Code: Azure-Anwendungen mit ARM-Vorlagen erstellen
Wenn es darum geht, Ressourcen in Azure bereitzustellen, dann sind ARM-Templates der beste Weg dafür. Daran wird sich auch auf absehbare Zeit nichts ändern. Allerdings – und das kennen wir ja auch – kann man nicht alles mit ARM Templates erreichen, auch wenn man schon wirklich viel und zum Teil auch komplexe Anforderungen damit abbilden kann (dank Variablen, Parametern und Funktionen). Und hier kommen „Deploymentscripts“ ins Spiel. Mit ihnen lassen sich in einem ARM-Template Skripte einbetten, die dann als Teil des Templates beim Deployment ausgeführt werden.
Außerdem wird es ein ARM Template Toolkit geben. Dieses Toolkit testet ARM Templates gegen Coding Best Practices.
Als weiteres Feature um ARM-Templates zu testen, wird es (zumindest in der Azure CLI) einen „whatif“-Schalter geben. Damit kann man sich anzeigen lassen, was passieren würde, wenn man ein Template deployed, ohne dass es wirklich deployed wird. In dem Beispiel ist zu erkennen, was sich ändern würde und was unverändert bleibt.
Der klassische Weg, ARM-Templates zu deployen, ist das Hochladen des Templates auf den eigenen Rechner. Danach wird es mit der Azure CLI oder per PowerShell in einer Ressourcengruppe deployed. Dabei muss man jedoch sicherstellen, dass das ARM-Template aktuell ist. Das kann schon mal nicht so einfach sein.
Eine Alternative dazu: Man verwendet das Template nicht lokal. Stattdessen wird in der Azure CLI oder der PowerShell auf eine URL verwiesen, wo ein Template zu finden ist. Allerdings muss es sich dabei um eine öffentlich erreichbare URL handeln. Das bedeutet, die Templates können sich nicht auf einem gesicherten Azure Storage oder Repository befinden.
Neue Möglichkeiten mit Template Specs
Mit Template Specs gibt es nun eine Möglichkeit, solche Templates an einer privaten, geschützten Stelle abzulegen und von dort aus zu verwenden. Dazu wird aus dem ARM-Template zusammen mit einem Package ein Template Spec generiert, die dann in einer „ARM Template Private Registry“ abgelegt werden kann. Diese Template Specs können dann für Deployments referenziert werden. Wie andere Registries (Nuget, NPM oder Docker Hub) werden die Templates Specs versioniert, so dass man auch gezielt auf eine ältere Version verweisen kann. Die „ARM Template Registry“ ist dabei eine native Ressource direkt in Azure.
Last but not least: Das Produkt-Team arbeitet an einer neuen „Language Revision“. Das bedeutet, dass man zukünftig Templates nicht mehr ausschließlich in JSON beschreibt. Stattdessen wird es für die Beschreibung von Templates eine DSL geben. Diese DSL wird sich an Terraform, den JSON-ARM- Templates und anderen Sprachen orientieren. Bisher steht diese neue Sprache noch nicht fest. Offenbar gibt es nur Überlegungen in diese Richtung. Das bedeutet auch, dass JSON-ARM-Templates nicht verschwinden werden.
Diese neue Sprache wird eine Abstraktion von Azure bedeuten (also doch wie Terraform?) und wird auf keinen Fall YAML sein. Aber die Sprache wird direkt darauf ausgelegt sein, dass man Ressourcen in mehreren Dateien beschreiben kann. Denkbar ist auch, dass diese Sprache in JSON als Zwischenschritt kompiliert wird, bevor dies dann an Azure für das Deployment übergeben wird.
Referenz: Infrastructure as code – build Azure applications with ARM templates
Erste Schritte beim Entwickeln für Microsoft Teams
Um für beziehungsweise in Teams zu entwickeln, gibt es verschiedene Extensibility Points:
– Tabs
– Messaging Extensions
– Bots
– Connectors
Je nach Use Case werden unterschiedliche Extensibility Points ausgewählt:
Für diese verschiedenen Extensibility Points gibt es das Microsoft Teams Toolkit, das beim Start eines neuen Projekts unterstützt. Aktuell gibt es das Toolkit für Visual Studio Code. Für Visual Studio wird es später noch eine entsprechende Extension geben.
Das Toolkit erinnert mich spontan schon stark an den „yo teams“ Yeoman Generator von Wictor Willen. Auf meine Frage der Abgrenzung des Toolkits zu dem Yeoman Generator war die Antwort:
„Well, the toolkit is from us – from Microsoft. The yeoman generator is from someone else.“ Vielleicht war das einfach nur unglücklich formuliert. Aber: Das Toolkit ist cool, weil es direkt in Visual Studio Code integriert ist.
Referenz: Getting started building for Microsoft Teams
IntelliCode – KI-gestützte Entwicklung jetzt und in Zukunft
IntelliCode ist kein neues Feature, denn es ist schon eine Weile in Visual Studio integriert. Bisher wurden aber ausschließlich öffentliche Repositories analysiert und auf dieser Basis Vorschläge in Visual Studio Code gemacht.
Für Azure DevOps gibt es nun eine Task, die man in seine Pipeline einfügen kann, so dass man aus dem erstellen Code ein Model trainieren kann. Diese Informationen sind direkt mit dem Repository verbunden, und nur die Personen, die Zugriff auf das Repository haben, können auch auf die Model-Daten zugreifen. Diese Daten liegen nicht direkt in dem Source-Code Repository, sondern in einem eigenen Service in Azure DevOps. Somit können aber gezielt Modelle für Repositories erstellt werden, so dass IntelliCode direkt aus den Konventionen des konkreten Repositories lernen kann.
Auch in Visual Studio selbst kann IntelliCode lernen. Werden zum Beispiel mehrere gleichartige Änderungen im Quellcode durchgeführt, kann IntelliCode anderen Stellen im Code vorschlagen, wo die gleichen Änderungen durchgeführt werden könnten. Die Demo zeigte, dass für LINQ-Abfragen Checks und Exceptions eingefügt wurden. Dabei variierten die Variablen-Namen im Code. Dennoch wurden für weitere LINQ-Abfragen die Checks und Exceptions vorgeschlagen. Das Ganze funktioniert so: Es werden die Deltas in dem AST (Abstract Syntax Tree) analysiert und dann andere Stellen gesucht, die eine vergleichbare Struktur aufweisen.
IntelliCode ist Teil von Visual Studio 2019, kann als Extension für Visual Studio Code heruntergeladen werden und ist auch in Visual Studio Online (aka Codespaces) verfügbar.
Referenz: IntelliCode – AI-assisted development, now and in the future
Automatisierte Tabellen-Kalkulationen mit Office Scripts in Microsoft Excel
Um Excel-Arbeitsmappen zu automatisieren, gibt es bisher verschiedene Möglichkeiten:
– VBA
– COM Addins
– Web Addins
Nun gibt es noch eine weitere Möglichkeit: Office Scripts!
Aktuell besteht das noch in der Preview und erfordert, dass ein Global Admin dieses Feature für den Tenant aktiviert. Office Scripts bieten dabei die Möglichkeit, dass Aktionen beziehungsweise Änderungen in einer Excel-Datei aufgezeichnet werden können. Als Ergebnis bekommt man Code. Das hört sich irgendwie nach Makros an? Nur: Office Scripts sind JavaScript!
So, wie einmal Makros hilfreich waren, die VBA API zu lernen, können Office Scripts helfen, die office.js API zu lernen. Damit ist klar: Diese Scripts funktionieren sowohl in „Excel on the web“ als auch in „Excel Desktop“ beziehungsweise meines Erachtens nach aktuell nur „on the web“. Die Office-Scripts können dabei als Teil einer Excel-Datei mit anderen optional geteilt werden.
Des Weiteren gibt es eine neue Action für Microsoft Power Automate (und wohl auch für Logic Apps), um Office Scripts in einer Excel-Datei auszuführen. Damit kann man sich also eine Excel-Datei vorstellen, die ein Office Script hat, um etwa Daten zu laden und sich selbst zu aktualisieren. Dieses Script könnte dann über Power Automate aufgerufen werden. So aktualisiert sich eine Excel-Datei irgendwo in OneDrive oder SharePoint.
Referenz: Automate spreadsheets with Office Scripts in Microsoft Excel
Distributed Application Runtime (DAPR)
Bei einer verteilten Anwendung ist es eine große Herausforderung, die verschiedenen (Micro-) Services miteinander zu verbinden. Dabei hat jeder Service seine eigene API, seine eigene Formatierung von Daten und auch eigene Rezepte für Retries und Fehlerbehandlung.
DAPR ist ein Framework, das an dieser Stelle die Rolle eines „Vermittlers“ einnimmt. Dabei sprechen die einzelnen Anwendungen nicht direkt miteinander, sondern immer nur mit DAPR.
DAPR verwendet sogenannte Bindings (definiert in YAML), um Endpoints zur Verfügung zu stellen, die dann aufgerufen werden können. Anstatt, dass eine Anwendung also direkt mit einem Redis-Cache spricht, um dort zum Beispiel seinen aktuellen Zustand zu speichern, spricht sie mit dem „State“ Building-Block von DAPR, der dann die Daten an Redis weiterleitet.
Dies ist vor allem vor dem Hintergrund interessant, dass man in einer produktiven Umgebung den Zustand nicht in Redis speichert, sondern etwa in Azure Tables. In einem solchen Fall müsste man nur das Binding in DAPR anpassen. In der Anwendung selbst muss keine Anpassung erfolgen.
Um einen Eindruck zu bekommen, empfiehlt sich ein Blick in die Demos auf YouTube.
Referenz: Distributed Application Runtime (DAPR)
