In diesem Beitrag werden wir die CI/CD Umgebung (wenn ihr nicht wisst, was das ist, könnt ihr es hier nachlesen) in Azure DevOps (die Lösung, die bis September 2018 noch Visual Studio Team Services, VSTS, also dem Microsoft Online-Angebot für kollaborative Projekte) fertig aufzusetzen (die ersten Schritte findet ihr in Teil 1).

Agenten und Pools

Zunächst werden wir uns eine Laufzeitumgebung für die Build-Prozesse von SSIS, SSAS oder SSRS-Projekten bauen. Das ist nötig, da es anders als beispielsweise für C# keine vorkonfigurierte von Microsoft gehostete Umgebung für Datenbank- oder BI Projekte gibt.

Im vorherigen Schritt habt ihr bereits eine neue leere Pipeline angelegt. Nun wollen wir diese mit Leben füllen. Der Schritt „Agent job 1“ im neuen, leeren Template braucht nun eine Entwicklungsumgebung, in der euer Projekt erstellt werden kann. Zur Auswahl stehen euch dabei mehrere vordefinierte und gehostete Umgebungen (beispielsweise Umgebungen für MacOS, Linux und Windows mit Visual Studio 2017).

Leider sind alle diese Umgebungen aber für das Kompilieren von Quellcode vorgesehen, die Data Tools, die wir für das Erstellen von BI- oder Datenbankprojekten benötigen, sind in keiner dieser Umgebungen installiert. Wir müssen uns als Datenbank-Entwickler also eine eigene Umgebung erzeugen in der wir ein Projekt erstellen können. Diese selbst gehostete (private) Umgebung müssen wir nun einrichten. Im Screensh

ot in Abbildung 1 sehen wir, dass im „Default“ genannten privaten Pool keine Agenten definiert sind, die eure Lösung erstellen könnten. Legen wir nun also einen eigenen Agenten in diesem Pool an. Dafür öffnet ihr den „Manage“-Link über dem Dropdown in Abbildung 1. Auf der so geöffneten Seite könnt ihr links den Agent Pool auswählen, den ihr bearbeiten wollt. Unter „Manage organization agent pools“ könnt ihr einen eigenen Agent Pool anlegen, wir werden fürs Erste aber mit dem „Default“ Pool arbeiten. Um euren eigenen Agenten in einem Agent Pool einzurichten, müsst ihr zunächst eine Maschine haben, auf der ihr eure Projekte erstellen könnt. Ich verwende hierfür eine VM in Azure, ihr könnt aber genauso gut eine lokale Maschine oder eine an anderer Stelle gehostete VM verwenden. Die Maschine braucht im Moment keine starke Hardware, wenn ihr größere und komplexere Projekte erstellen und testen wollt, solltet ihr aber darauf vorbereitet sein, sie zu skalieren.

 

Den Agenten verfügbar machen

Bisher haben wir gesehen, dass wir für die Build-Umgebung einen Build Agent in einem Agent Pool einrichten müssen. Das wollen wir jetzt durchführen. Um die im vorherigen Schritt provisionierte Hardware (oder VM) für Build-Prozesse verfügbar zu machen, muss sie für Azure DevOps erreichbar sein. Das bedeutet, dass auf der Build-Maschine ein Stück Software laufen muss, dass Azure DevOps aus der Cloud den Zugriff auf die Maschine ermöglicht und es erlaubt, dort Prozesse wie die Build-Prozesse auszuführen. Diese Software ist der „Agent“. Um den Agenten zu installieren müsst ihr ihn von der Azure DevOps Homepage herunterladen, den Link hierfür findet ihr auf der Seite zur Verwaltung der Agent Pools (ihr könnt ihn in Abbildung 2 oben sehen). Der Agent kommuniziert über den Port 443 mit Azure DevOps, dieser Port sollte also in der Firewall und auf der Maschine outbound zur Verfügung stehen. Der generelle Prozess ist dann wie folgt:

• Ihr registriert den Agenten bei einem Agent Pool (dafür braucht ihr mindestens die Rechte des Agent Pool Administrators, die ihr aber wenn ihr diesem Tutorial folgt in jedem Fall habt. Der Agent speichert sich diese Credentials natürlich nicht, sie werden ausschließlich für die Installation verwendet.
• Der Agent prüft, wenn er aktiv ist in regelmäßigen Abständen, ob eure Pipelines neue Jobs in die Build Queue des Agent Pools geschrieben haben. Wenn es einen neuen Job gibt, lädt der Agent sich diesen Job sowie ein dazugehöriges Job-spezifisches OAuth-Token herunter. Dieses Token erlaubt es dem Agenten auf die Ressourcen des Jobs lesend (z.B. Quellcode) oder Schreibend (z.B. erstellte Binaries) zuzugreifen.
• Wenn der Job abgearbeitet wurde, verwirft der Agent das Token und beginnt wieder nach neuen Jobs in der Job Queue zu suchen.

Wir werden nun gemeinsam den Agenten einrichten. Bevor ihr den Agenten installiert und konfiguriert, müsst ihr noch dafür sorgen, dass er auch mit eurem Azure DevOps kommuniziere

n kann. Damit das funktioniert, müsst ihr mit eurem Benutzerkonto ein Zugriffstoken anlegen, mit dem sich der Agent für die Kommunikation gegenüber Azure DevOps authentifizieren kann. Um dieses Token anzulegen, Klickt ihr in der oberen rechten Ecke der Azure DevOps Seite auf euer Profil und wählt dort den Me

nüpunkt „Security“ aus (Abbildung 3). Auf der Seite, die sich nun öffnet, könnt ihr links den Reiter „Personal Access Tokens“ (PAT) auswählen und auf der sich nun öffnenden Seite „Add“ anklicken, um einen neuen Token anzulegen (Abbildung 4).

 

Beim Anlegen des Tokens müsst ihr nun einen (möglichst sinnvollen, sprechenden) Namen für den Token vergeben. Dann legt ihr die Lebensdauer des Token fest und die Organisation(en) für die er gültig sein soll. Da wir nur eine Organisation ausgewählt haben, haben wir hier keine Optionen, wenn ihr euch in einem Firmen-Umfeld bewegt, könnten allerdings schon einige Organisationen existieren, aus denen ihr die auswählt, die euer aktuelles Demo-Projekt beinhaltet.

Als Lebensdauer des Token habe ich in Abbildung 5 ein Jahr ausgewählt, um den Token nicht zu oft erneuern zu müssen, es steht euch aber natürlich frei, hier auch eine andere Lebensdauer auszuwählen. Bei

m Scope habe ich „All scopes“ ausgewählt. Ihr könnt aber natürlich hier auch eine Einschränkung auf bestimmte Scopes und damit Rechte durchführen. Ein Klick auf „Create Token“ legt euch nun den Zugriffstoken für euren Agenten an. Achtung, stellt auf jeden Fall sicher, dass ihr auf der Seite, die sich nun öffnet, den Wert des Token (also den kryptischen Text, der euch angezeigt wird) kopiert, denn ihr werdet ihn gleich noch brauchen und habt später keinen Zugriff mehr darauf.

Beim Download des Agenten bekommt ihr wie in Abbildung 6 von Azure DevOps die Anleitung für seine Installation direkt mit angezeigt. Ladet also den Agenten herunter und folgt der Installationsanleitung, indem ihr zunächst auf dem Root-Verzeichnis eurer Festplatte (C:\) ein Verzeichnis mit dem Namen „agent“ anlegt u

nd dort hin wechselt.

Dann entpackt ihr den Agenten, den ihr vorher in einer ZIP-Datei heruntergeladen habt. Ein Shell-Skript, das diesen Vorgang nach dem Download des Agents ausführt, haben wir für euch in unserem GitHub Repository hinterlegt. Nach dem Entpacken der Datei findet ihr im Verzeichnis C:\agent zwei Unterverzeichnisse und zwei Shell-Skripte zum Konfigurieren und Ausführen des Agenten.

Im nächsten Schritt konfiguriert ihr den Agenten indem ihr das „config.cmd„-Skript ausführt (es wäre gut, wenn ihr das in einer Shell mit Admin-Rechten tut). Hier werdet ihr zunächst nach der Server-URL des Servers eurer Quellcode-Verwaltung gefragt. Da wir Azure DevOps verwenden, lautet diese URL https://dev.azu

re.com/{eure-organisation},  den Wert für „eure-organisation“ müsst ihr hier natürlich noch durch die Organisation, die ihr auch in eurer visualstudio.com-URL findet, ersetzen. Als nächstes müsst ihr die Art der Authentifizierung auswählen. Da wir bereits den PAT angelegt haben, drückt ihr hier einfach nur Enter. I

m folgenden Schritt müsst ihr jetzt noch den vorher kopierten Token einfügen. Um die Konfiguration des Agenten abzuschließen fehlen jetzt nur noch einige Angaben, die ihr alle mit Return bestätigen könnt. Diesen Vorgang könnt ihr in Abbildung 7 sehen.

Ihr habt nun einen Agenten für die Kommunikation mit Azure DevOps angelegt und konfiguriert. Ihr könnt ihn nun mit dem „run.cmd“-Kommando ausführen. Der Agent verbindet sich dann mit dem Server und Teilt euch durch die Meldung „Listening for Jobs“ mit, dass er bereit ist, Build-Jobs von eurer Umgebung entgegen zu nehmen. Das könnt ihr auf der Übersichtsseite eures Agent Pools verifizieren, wo euer Agent jetzt als „Online“ und „idle“ angezeigt wird.

Die Build-Umgebung einrichten

Auf der VM, die den Build Agent ausführt, installiert ihr nun die Entwicklungsumgebung für eure Datenbank-Projekte. Das bedeutet, dass ihr dort Visual Studio und die SQL Server Data Tools in der für euren Server passenden Version installiert. Wir verwenden Visual Studio 2017 Community Edition und die SQL Server Data Tools für SQL Server 2017.

Damit habt ihr eine Umgebung eingerichtet, die mit Azure DevOps kommunizieren kann und in der Lage ist, eure BI- und Datenbankprojekte zu erstellen und zu testen. Wie ihr die Build- und Test-Prozesse für verschiedene Projekt-Typen (SSIS, SSAS oder Datenbankprojekte) einrichtet, erklären wir in den nächsten Beiträgen.