In diesem Beitrag möchten wir anfangen uns eine CI/CD Umgebung in Azure DevOps (bis September 2018 hieß diese Lösung noch Visual Studio Team Services, also VSTS. Sie ist das Microsoft Online-Angebot für kollaborative Projekte) aufzusetzen. Wir werden dabei besonderes Augenmerk darauf legen eine solche Umgebung für Projekte rund um den SQL Server (also für SSIS, SSAS, SSRS und Datenbankprojekte) einzurichten. Anders als bei der Softwareentwicklung gibt es hier keine fertigen Templates und keine vorgefertigten Umgebungen zum Kompilieren und Veröffentlichen von Lösungen.
Was wir zuerst brauchen: Ein Azure DevOps-Projekt
Um mit dem Continuous Integration Teil von CI/CD zu beginnen, müsst ihr zunächst eine Umgebung aufsetzen, in der ihr euer Projekt automatisch erstellen (builden) könnt. Für die meisten Programmiersprachen existieren mehrere CI-Tools mit verschiedensten Build Umgebungen, wir werden hier das Aufsetzen einer solchen Umgebung in Azure DevOps erklären. Zunächst müsst ihr euch dafür auf https://www.visualstudio.com anmelden. Dafür benötigt ihr einen Microsoft-Account, den ihr aber, falls ihr ihn noch nicht habt, direkt bei der Anmeldung anlegen könnt. Mit diesem Account könnt ihr nun in Azure DevOps Projekte anlegen. Bis zu 5 Personen können dabei kostenlos am Projekt mitarbeiten. User die einen MSDN Account besitzen, sind von dieser Anzahl ausgenommen, hier könnt ihr so viele User zu eurem Projekt hinzufügen, wie ihr wollt.
Wenn ihr euren Account angelegt habt, werdet ihr gebeten eine Organisation zu erstellen. Diese Organisation wird am Ende eure URL definieren. Da wir für diesen Blog die Organisation „Continuous Intelligence“ angelegt haben, sind unsere Azure DevOps-Projekte nun unter https://continuous-intelligence.visualstudio.com erreichbar. Ihr solltet euch hier gegebenenfalls mit eurem Arbeitgeber abstimmen, damit ihr nicht einen Organisationsnamen verwendet, der den Firmennamen enthält und damit für spätere Firmen-Projekte möglicherweise nicht mehr zur Verfügung steht.
Nachdem eure neue Organisation angelegt wurde, könnt ihr nun direkt loslegen und ein Projekt erstellen. Die Maske für das Anlegen eines neuen Projekts seht ihr in Abbildung 2. Neben dem Namen für das Projekt könnt ihr hier auswählen mit welcher Versionskontrolle ihr den Code verwalten wollt. Zur Auswahl stehen hier Git oder der Team Foundation Version Control. Welche Versionierung ihr auswählt hat einerseits mit euren persönlichen Präferenzen und andererseits mit der Arbeitsweise eures Teams zu tun. Im BI- und Datenbankenbereich ist TFVC immer noch sehr populär, im Bereich der Software-Entwicklung hat sich in weiten Teilen Git durchgesetzt. Wir werden hier und in den nächsten Beiträgen mit Git arbeiten, die Lösungen, die wir zeigen lassen sich jedoch in der Regel einfach auf TFVC übertragen.
Nun habt ihr schließlich noch die Wahl wie ihr die Arbeitspakete in eurem Projekt managen möchtet. Ihr habt hier die Wahl zwischen „agil“, „CMMI“ oder „Scrum“. Da diese Wahlmöglichkeit keinerlei Einfluss auf den CI/CD-Prozess hat, können wir sie hier getrost ignorieren (bzw. einfach auf „agil“ eingestellt lassen).
Direkt nach dem Anlegen des Projekts wird Azure DevOps euch auffordern eine CI/CD-Umgebung für das Projekt anzulegen. Wenn ihr das tut, könnt ihr im nächsten Schritt zwischen vorgefertigten (in der Cloud gehosteten) Umgebungen auswählen oder euch eine eigene Umgebung aufsetzen. Die in der Cloud gehosteten Umgebungen haben den Vorteil, dass sie für euch keinerlei Maintenance Aufwand bedeuten. Dafür haben sie den Nachteil, dass sie ab einem gewissen Kontingent an Build-Vorgängen kostenpflichtig sind. „Zum Glück“ müsst ihr euch nicht entscheiden ob ihr eine selbst gehostete Build-Umgebung oder eine von Microsoft bereitgestellte Umgebung in der Cloud nutzen wollt, da Datenbank-Entwickler wie so oft bei derartigen Tools etwas stiefmütterlich behandelt werden und es daher keine fertigen Umgebungen gibt, mit denen Datenbank-, SSIS, SSAS oder SSRS-Projekte erstellt werden könnten. Wir werden euch deshalb im nächsten Schritt erklären wie ihr eine Build-Umgebung selber hosten könnt.
Der nächste Schritt: Erstellen einer Build Pipeline
Nachdem ihr das Projekt eingerichtet habt, müsst ihr dem Projekt Code hinzufügen. Da wir im Moment noch nicht mit Code arbeiten wollen, sondern uns zunächst die Umgebung einrichten werden, wählen wir die Option das Projekt zunächst mit einer README-Datei zu initialisieren.
Daraufhin wird das Projekt angelegt und eine Markdown-Datei als README erzeugt. Anstatt mit einem komplett leeren Projekt zu beginnen, hätten wir natürlich auch ein existierendes Projekt zur Quellcodeverwaltung hinzufügen können. Nachdem ihr das Repository der Quellcodeverwaltung mit der ersten Datei initialisiert habt, fordern die Visual Studio Team Services euch auf, für das Projekt Continuous Integration zu verwenden und einzurichten (Abbildung 4).
Hier machen wir einen kurzen Exkurs zur Terminologie: Azure DevOps bezeichnet einen AzureDevOps-Prozess als „Pipeline“. Dieses Wording ist nicht vom Tool abhängig, sondern im CI/CD-Kontext durchaus üblich: Beim überaus populären Automatisierungs-Server Jenkins spricht man beispielsweise von „Build-Jobs“, die in „Pipelines“ orchestriert werden. Üblicherweise ist damit im CI/CD Kontext die Steuerung von mehreren (möglicherweise länger laufenden) Aktivitäten in Abhängigkeit der Resultate der vorangegangenen Aktivitäten gemeint. Typische Pipelines beinhalten Prozesse wie „hole eine bestimmte Version des Quellcodes aus dem Repository“, „Erstelle das Projekt mit diesem Quellcode“ oder „führe automatisierte Tests dieses Builds aus“.
Wenn ihr also euer Repository initialisiert habt, könnt ihr wie in Abbildung 4 gezeigt eure erste Pipeline initialisieren. Dafür wählt ihr zunächst aus, aus welcher Quelle der Quellcode stammen soll:
Im nächsten Schritt werden euch verschiedene Templates für den Build-Prozess angeboten. Wie bereits erwähnt gibt es allerdings nichts für SQL-Entwickler (auch die Suche nach SSIS, SSAS oder SSRS bleibt leider ergebnislos. Es bleibt euch also nicht viel übrig, als mit einem neuen, leeren Template zu starten („Start with an empty job“).
Azure DevOps legt nun für euch eine Pipeline an, die Schritte „Get Sources“ und einen Ominösen „Agent job 1“ enthält. Ihr seid jetzt soweit dass eure Entwicklungsumgebung für das Aufsetzen eines CI/CD Prozesses vorbereitet ist. Im nächsten Beitrag werden wir gemeinsam den „Agent job 1“ einrichten, uns Gedanken darüber machen, wo und wie ein Build überhaupt erfolgen kann (bzw. was für Tools wir dafür benötigen) und die Umgebung für Continuous Integration fertig aufsetzen.