Precompiled Azure Functions

Teil 3: Continuous Integration

Nachdem wir in Teil 1 des Blogbeitrags über die Vorteile von Precompiled Azure Functions gelesen haben und uns in Teil 2 mit der Vorlage beschäftigt haben, fehlt zu guter Letzt noch eine Möglichkeit unseren entwickelten Code kontinuierlich zu bauen und zu integrieren.

Server Builds und Continuous Integration Prozesse können mit den unterschiedlichsten Toolchains abgebildet werden. In unserem Beispiel nutzen wir Visual Studio Team Services (VSTS) mit einem FTP Release Management.

Der Quellcode der Vorlage liegt als Git Repository auf GitHub. Diese Repository kann als Quelle für VSTS Builds und Releases genutzt werden. Zunächst erstellen wir ein neues VSTS Projekt, welches als Grundlage für Builds und Releases dient. Danach konfigurieren wir einen Build, der mit jedem Commit eine neue Version der Precompiled Azure Functions baut. Abschließend erstellen wir einen Release-Prozess für die Testumgebung. Natürlich könnt ihr die folgende Beschreibung auch mit eurer eigenen Repository durchführen.

Der Build-Prozess

  1. Wir erstellen einen neuen Build auf Basis einer leeren Vorlage
  2. Bevor unser Quellcode in VSTS gebaut werden kann, muss sich VSTS die Sourcen zuerst holen. Wie bereits erwähnt, erlaubt VSTS die direkte Einbindung von GitHub Repositories. Habt ihr noch keine vertrauenswürdige Verbindung zu GitHub aufgebaut, führt euch an dieser Stelle ein Wizard durch den Authentifizierungsprozess.

  3. Restore der NuGet Pakete: Wir benötigen diesen Extraschritt, da der folgende „Visual Studio Build“ Schritt in seinen Einstellungen darauf verweist, dass man NuGet Pakete gesondert behandeln soll. Dieser Schritt muss nur vorhanden sein. Die Konfiguration entspricht der Standardkonfiguration.

  4. Es gibt in VSTS verschiedene Möglichkeiten Builds zu erstellen. Ich habe mich hier für einen Visual Studio Build entschieden, der direkt die Visual Studio 2017 Einstellungen für den Build-Prozess nutzt. Bis auf die drei markierten Punkte muss nichts weiter konfiguriert werden.

  5. Abschließend stellen wir die Artefakte für den Release-Prozess bereit.

Der Release-Prozess

Mit dem Release-Prozess setzen wir auf erfolgreiche Builds auf und veröffentlichen das Ergebnis in unseren Test- bzw. Produktiv-Umgebungen.

  1. Zuerst erstellen wir einen neuen Release auf Basis einer leeren Definition.
  2. Als nächsten Schritt konfigurieren wir die Basis für den Release.

    Wir möchten den Release auf Basis eines vorherigen Builds erstellen (1). In (2) und (3) stellen wir sicher, dass der korrekt Build ausgewählt wird. Bei (4) setzen wir das Häkchen, da wir eine voll automatisierte Veröffentlichung anstreben.
  3. Wir erstellen einen Release Task: Einen FTP Upload.

    Bei (1) wählen wir einen zuvor erstellten Serviceendpunkt aus. Über den Punkt „Manage“ können neue Endpunkte per Wizard erstellt werden (Benutzer, Passwort und FTP Endpunkt werden hier definiert). Mit (2), (3) und (4) wird definiert, welche Dateien veröffentlicht werden sollen und wohin. Wichtig ist (5) – ist dieser Haken nicht gesetzt, wird beim FTP Upload die Ordnerstruktur verworfen!
  4. Bevor wir fertig sind, müssen wir die Einstellungen des Environments prüfen. Wir wollen ein automatisiertes Veröffentlichen in unsere Testumgebung erreichen.
  5. Das Register „Approvals“ sollte so aussehen.
  6. Bei den „Deployment conditions“ sammeln wir die Releases im Falle von parallel laufenden Builds.

Wir haben nun einen automatisierten Build mit anschließendem Release konfiguriert. Was kommt jetzt?

Von hier an, können wir allerlei Optimierungen vornehmen und den Continuous Integration Prozess an individuelle Bedürfnisse anpassen. Das Thema rund um die kontinuierliche Integration ist sehr vielschichtig und kann mit steigenden Anforderung komplex werden.

In diesem Blogbeitrag konzentriere ich mich auf die Bereitstellung der Precompiled Azure Functions Vorlage für Visual Studio 2017. Es würde den Rahmen sprengen, an dieser Stelle tiefer in den kontinuierlichen Integrationsprozess einzusteigen.

Abschließend möchte ich euch jedoch ein paar Gedanken zu Verbesserungen mitgeben:

  • Wir haben exemplarisch eine Veröffentlichung in einer Testumgebung konfiguriert. Es wäre ein einfaches Unterfangen, ein weiteres „Environment“ für die Produktivumgebung zu erstellen. Kopiert dazu das vorhandene „TestEnvironment“ und ändert den „FTP Service Endpoint“ auf eine produktive Azure Functions App. Zusätzlich könnt ihr noch „Approvals“ bei der Umgebung hinzufügen und schon wird der Release nicht mehr automatisiert erfolgen. Der Release muss dann freigegeben und gestartet werden.
  • Bei der Buildkonfiguration haben wir noch keine Unit Tests berücksichtigt. Wie wäre es, wenn wir einen zusätzlichen Schritt für den „Visual Studio Test“ einfügen würden?
  • Als Sahnehäubchen bietet Azure selbst die Möglichkeit Load Tests auf die Test- oder Produktivumgebung durchzuführen.
  • Zusätzliche Tools, wie z.B. „Postman“ bieten die Möglichkeit für Integrationstests. Veröffentlichte Webservices können damit automatisiert getestet werden.

Die Möglichkeiten scheinen grenzenlos und die beste Konfiguration für die eigene Situation zu finden ist manchmal nicht ganz einfach. Wenn euch der Dschungel zu dicht wird und Ihr Hilfe benötigt, zögert nicht unser Team zu kontaktieren – wir helfen gerne aus.

Zusammenfassung

Im ersten Teil des Blogbeitrags habe ich euch Precompiled Azure Functions, sowie deren Vorteile vorgestellt. In Teil zwei habt ihr eine Visual Studio Vorlage an die Hand bekommen, mit der ihr leicht in die Entwicklung eurer eigenen kompilierten Funktionen einsteigen könnt. Abgerundet haben wir das Thema mit der kontinuierlichen Veröffentlichung unseres Quellcodes.

Mit Precompiled Azure Functions vereinen wir die Unkompliziertheit von Azure Functions mit den Produktivitätsvorteilen von Visual Studio. Wir können schnell und direkt an der Business-Logik entwickeln, ohne auf die täglichen Dinge zu verzichten, die nachhaltige Softwareentwicklung ausmachen.

Ich wünsche euch nun viel Spaß beim Abtauchen in die Welt von Precompiled Azure Functions!

Vielen Dank für eure Aufmerksamkeit