Einführung

Azure ist einer der Cloud Services von Microsoft und bietet:

• Infrastructure as a Service (IaaS): Cloudserver, Cloudspeicher, Netzwerktechnologien (Firewall, VPN, Loadbalancer…)
• Platform as a Service (PaaS): VMs, Container Apps, Kubernetes, Functions…
• Service as a Service (SaaS): Office, CRM, ERP…

DevOps stellt einen Dienst von Azure dar, um die Organsation und Entwicklung von Software Produkten zu unterstützen.

DevOps is a set of practices intended to reduce the time between committing a change to a system and the change being placed into normal production, while ensuring high quality

(Bass, Len; Weber, Ingo; Zhu, Liming (2015). DevOps: A Software Architect’s Perspective. ISBN 978-0134049847)

DevOps unterstützt und verknüpft mit dessen verschiedenen Werkzeugen verschiedene Praktiken der Software Produkt Entwicklung  (lt. WIkipedia : https://en.wikipedia.org/wiki/DevOps):

• Coding – code development and review, source code management tools, code merging.
• Building – continuous integration tools, build status.
• Testing – continuous testing tools that provide quick and timely feedback on business risks.
• Packaging – artifact repository, application pre-deployment staging.
• Releasing – change management, release approvals, release automation.
• (Configuring – infrastructure configuration and management, infrastructure as code tools.)
• (Monitoring – applications performance monitoring, end-user experience.)

Die beiden letzten Punkte sind jedoch nicht in Azure DevOps vertreten.

Was wollen wir zeigen?

Anhand eines Beispiels wollen wir präsentieren wie DevOps Prinzipien in Azure umgesetzt werden können.
Dabei sollen verschiedene Protagonisten (Stakeholder/Product Owner, Entwickler, Betrieb) an dem Prozess teilhaben um die Fähigkeiten der Azure DevOps Plattform hervorzustellen.

Boards

Azure Boards bietet Tools zum Organisieren von Software Entwicklung. Das Ziel ist das schnelle Nachvollziehung von User Storys, Fehlern, Features und Epics. Es werden vier verschiedene Prozessarten unterstützt die man zum erstellen des Projektes wählt: Agile, Basic, Scrum, or Capability Maturity Model Integration (CMMI)

Dieser Artikel beschreibt die Funktionen der agilen Prozess Art.

Planen und Nachverfolgen der Arbeit

Zunächst ist in Boards eine einfache Planung und Nachverfolgung der Arbeit innerhalb des Teams möglich. Zum einen für den Projekt Manager, als auch für die Entwickler, Tester, Designer, ect. des Teams.

Konfiguration der Prozessart

Die verschiedenen Arbeitsprozesse bieten verschiedene Typen für die sogenannten ‚Workitems‘. Bei der Wahl eines Agilen Prozesses sind diese unter anderem User Stories, Tasks, Bugs, Features und Epics. Des weiteren bieten die verschiedenen Prozesse passende Statusbezeichnungen. Im Fall des agilen Prozesses sind diese ‚New‘, ‚Active‘ und ‚Resolved‘.

Innerhalb jedes Workitems kann unter anderen die Aufgabe näher beschrieben, ein Bearbeiter zugeordnet und mit anderen darüber ausgetauscht werden. Des weiteren können direkt von Workitems aus Branches in der Versions-Kontrolle erstellt werden. Damit sind die Branches direkt mit dem jeweiligen Item verknüpft.

Anlegen neuer Workitems

Nach der Erstellung eines Projektes können direkt Workitems erstellt und hinzugefügt werden. Über das User-Story-Kanbanboard (erreichbar durch das Menü-Element ‚Boards > Boards‘) lassen sich am besten neue User Stories und Child-Tasks erstellen. Das Board lässt sich des weitern auf Ebene der Features betrachten und bietet eine gute Möglichkeit um Features und entsprechende Child Tasks anzulegen.

Projektorganisation mit Scrum Tools

Mit dem Scrum-Tools von Azure Boards lassen sich Sprints planen und durchführen. Aus dem Backlog des Projektes kann dafür in der Planung ein Sprint-Backlog aufgebaut werden. In dem Menüpunkt ‚Boards > Backlog‘ lässt sich der Backlog organisieren und Items aus dem Backlog in die zu planende Iteration hinzufügen. In dem Menüpunkt ‚Boards > Sprint‘ lässt sich anschließend das Sprintboard, dessen Backlog und der Burndown anzeigen und überwachen.

Anpassen der Boards

Die verschiedenen Boards können jeweils angepasst werden. Häufige Personalisierungen sind:

• Felder: Welche Felder werden für jedes Workitem angezeigt
• Spalten: Spalten hinzufügen, umbenennen und bearbeiten
• Unterteilung: Das Board kann in Priorität, Service Klassen oder geblockte Items unterteilt werden mit ‚Swimlanes‘
• Backlog: Für Epics und Issues kann das Tracking aktiviert/deaktiviert werden

Repos

Azure Repos ist ein Service der die Versionskontrolle und Code Verwaltung ermöglicht. Dabei wird das Git Versionskontrollsystem verwendet. Es werden die bei Git üblichen Funktionen angeboten, wie Branches, Commits, Pull-Requests erstellen etc. Darüber hinaus bietet Azure DevOps in der Weboberfläche die Möglichkeit unterschiedliche Aspekte des Versionskontrollsystems zu verwalten. Unter anderem lassen sich Pull-Requests bearbeiten, die Commit Historie kann eingesehen werden und die Dateien und Ordner in dem Repository angezeigt und bearbeitet werden.

Neben Git lässt sich auch die Team Foundation Versionskontrolle verwenden (die ist im Gegensatz zu Git zentralisiert).

Einbindung von Git in DevOps

Um den Mehraufwand bei der Entwicklungsarbeit zu verringen, lassen sich Ereignisse die in der Arbeit mit dem Repository auftreten mit weiteren Bereichen des DevOps Services verbinden. Eine Möglichkeit ist, Workitems (Tickets, Storys etc.) mit einem Branch zu verknüpfen. Bei entsprechender Konfiguration führt das Mergen eines Branches in einen Anderen dazu, dass alle, mit dem ersten Branch verknüpften, Tickets geschloßen werden.

Ein weiteres Beispiel ist das automatische Anstoßen einer Build-Pipeline, falls in einem bestimmten Branch ein neuer Commit registriert wird.
Um auf dem eigenen Rechner mit der Arbeit an einem Projekt zu beginnen, das in Azure Repos lebt, muss im DevOps Projekt zunächst ein öffentlicher SSH Schlüssel vom eigenen Rechner hinterlegt werden. Ab da können wie gewohnt die Git Kommandos auf der Kommandozeile oder über die IDE ausgeführt werden.

Workflow

Ein üblicher Workflow, der die verschiedenen Funktionen von Azure Repos nutzt könnte folgenderdermaßen aussehen:

• der*die Entwickler*in findet in DevOps Boards ein neues Ticket
• er*sie erstellt direkt aus der Ticket-Ansicht heraus einen neuen Branch
• lokal wechselt er*sie auf den neu erstellten Branch und beginnt zu arbeiten
• nach getaner Arbeit pusht er*sie das Ergebnis und erstellt über DevOps einen Pull-Request
• ein Senior Developer begutachtet diesen
• er*sie befindet die Änderungen als gut und führt den Merge in den develop Branch durch
• damit schließt sich automatisch das Ticket und eine Pipeline wird angestoßen, welche den neuen Stand des develop
  Branches baut und daraufhin auf eine Entwicklungsumgebung deployed

Pipelines

Bereich Build-Pipelines

1. Eine Build-Pipeline erstellen

Um eine Pipeline zu erstellen, gehen wir unter „Pipelines“ –> „Pipelines“.

2. Bestimmung der Pipeline Art

Es besteht die Möglichkeit zwischen zwei Arten von Pipelines zu wählen. Die erste Option basiert auf einer YAML-Datei (XML in der UI) und die zweite Option „Use the classic editor“ finden wir unten und bietet eine grafische UI an.

2.1 Vor- und Nachteile

	YAML	Classic
Code Review	Ja	–
Security-Richtlinien	–	Ja
Sicherheit vor Veränderung	–	Ja
Sicherheit vor Sichtbarkeit	–	Ja
Einfache Verständlichkeit	–	Ja
Unterstützung beim Aufbau	–	Ja
Vordefinierte Templates	–	Ja

 

 

In diesem Beispiel wurde der klassische Editor gewählt.

3. Woher kommt der Quellcode?

Es ist gleich woher der Quellcode für die Pipeline stammt. Azure DevOps stellt sehr viele Möglichkeiten zur Verfügung. Sei es durch direkte Integration wie GitHub oder andere Git-basierte Quellcodeverwaltungssysteme.

4. Auswahl eines Template

Von Haus aus stellt Azure DevOps eine große Anzahl von Templates zur Verfügung. Docker container, Android Apps, Desktop Anwendungen, usw. Und falls diese Möglichkeiten nicht reichen, können über den „Marketplace“ weitere Templates heruntergeladen werden. [Azure DevOps Marketplace](https://marketplace.visualstudio.com/search?target=AzureDevOps&category=Azure%20Pipelines&sortBy=Installs)

4.1 Leeres Template

Dies ist das Standard Template von Azure DevOps.

4.2 ASP Core Template

Dies ist das Template für eine ASP NET Core Web-Anwendung. Ohne weitere Klicks ist diese Pipeline voll funktionstüchtig. Abhängigkeiten laden, Anwendung bauen, testen und innerhalb von Azure DevOps zur Verfügung stellen.

5. Variablen

Variablen werden genutzt, um innerhalb der Pipeline Werte zu hinterlegen. Diese können durch folgende Syntax verwendet werden: $(NameDerVariable). Dies bietet einen zentralen Ort zum Speichern von Informationen. Man kann sie über „Variable groups“ mit anderen Pipelines teilen. Ein weiteres Feature ist das „verstecken“ von Variablenwerten für Passwörter, Datenbankverbindungen und andere sensible Informationen.

6. Trigger

Hier wird das eigentliche „Continuous integration“ definiert. Wählen wir die Option „Enable continuous integration“ so wird die Pipeline jedes mal ausgeführt, wenn neuer Quellcode zum Repo hinzukommt. Dies kann man auf einen oder mehrere Branches und zusätzlich Pfade innerhalb eines Projektes beschränken.

Eine andere Option ist die zeitgesteuerte Ausführung.

Zum Schluss kann man noch eine andere Build-Pipeline anstoßen, wenn diese erfolgreich durchgelaufen ist.

7. Options

Hier sind einige hilfreiche Features hinterlegt. Das „build number format“ gibt das Anzeigeformat des Durchlauf der Pipeline an. Auch die „Status badges“ sind nützlich für einen schnellen Überblick über alle Pipelines.

8. History

Für die Nachverfolgung von Änderungen ist der Historien Bereich mehr als nützlich. Hier kann nicht nur eingesehen werden wer wann was geändert hat, sondern auch zu welchem Wert der Vorherige geändert wurde.

Bereich Release-Pipelines

1. Eine Release-Pipeline erstellen

Unter dem Reiter „Pipelines“ –> „Releases“ können wir eine neue Release-Pipeline erstellen.
Andere Punkte:

• Environments : Ressourcen für eine YAML-Pipeline für Container und virtuelle Maschinen
• Library: Definition von Variablen-Gruppen und sicheren Dateien
• Task groups: Vordefinierter Prozess in Tasks aufgeteilt
• Deployment groups: Vordefinierter Prozess für ein Release/Stage

2. Auswahl eines Templates

Als erstes wird nach einem Template gefragt. Hier können wir aus dutzenden vorgefertigten Abläufen wählen oder mit einem leeren „Empty job“ Ablauf starten.
Beispiele für Vorlagen:

• Azure App Service
• Kubernetes cluster
• IIS website and SQL database
• andere Datenbanken

Wie bei anderen Vorlagen können auch hier weitere aus dem Marketplace heruntergeladen werden.

 

3. Leeres Template

Ein Beispiel für eine leere Vorlage. Hier wird alles von Grund auf selbst definiert.

4. Auswahl des Quellcodes über eine Pipeline

Als nächstes definiert man eine oder mehrere Quellen von seinen Anwendungen die veröffentlicht werden soll. Sie sind als „Artifacts“ hinterlegt und werden über die Build-Pipelines zur Verfügung gestellt. Das Einbinden von externen Quellen wie GitHub ist ebenfalls möglich. Man kann mit einer Release-Pipeline gleich mehrere Anwendungen auf verschiedene Ziele veröffentlichen.

 

5. Continuous deployment aktivieren

Um eine vollwertige CI/CD Pipeline einzurichten, möchten wir, nachdem unser Projekt erfolgreich gebaut wurde, diese danach automatisch auf bestimmte Ziele veröffentlichen. Dazu klicken wir auf das Blitz-Symbol unser Quelle. Hier eine Build-Pipeline. Danach öffnet sich das Fenster auf der rechten Seite. Wir aktivieren den Punkt „Enabled“. Jetzt wird die Release-Pipeline getriggert, jedes mal, wenn die Build-Pipeline erfolgreich durchgelaufen ist. Auch hier kann man mit den „Build branch filters“ erneut den Branch spezifizieren.

6. Stageweises veröffentlichen einer Anwendung

In diesem Beispiel wird eine Anwendung auf verschiedene Stages veröffentlicht. Eine „Stage“ ist eine bestimmte Umgebung. Entweder kann sie jeweils einen Server repräsentieren oder, für eine Web-Anwendung, jeweils eine bestimmte Subdomain. Bsp.: dev.example.de, qa.example.de, test.example.de, example.de .
Bei diesem Aufbau kann man erst die Anwendung auf TEST veröffentlichen, wenn sie vorher auf dem DEV & QA Stage waren.

7. Trigger/Gates für Stages

Klickt man bei einem Stage auf das Blitz/Person-Symbol (hellblau Hintergrund) kann man „Pre-deployment conditions“ definieren.

• nach einem bestimmten Stage („Stages“)
• wenn eine Person oder Gruppe zustimmt („Pre-deployment approvals“)
• manuell veröffentlichen („Select trigger“)
• Aktion ausführen („Gates“) z.B.: Api-Request

 

 

8. Spezifischer „deployment task“

Innerhalb der Stage kann man den genauen Prozess spezifizieren, wie die Anwendung auf das Ziel kommt. Hier kann beinahe jede bekannte Methode verwendet werden. Z.B.: SSH, (S)FTP, Google Play Store, verschiedene Datenbanken, jeder Azure Service und viele weitere Verbindungsvorlagen (über Marketplace erhältlich).  Aufgebaut wird sie wie eine Build-pipeline.

9. Variablen

Die Variablen ähneln stark denen der Build-Pipeline. Zusätzlich kann man hier einen „Scope’s“ definieren. Eine Scope bildet eine Stage ab bzw. ein „Release“, welches als default value dient, falls diese Variable für alle Stages vorgesehen ist.

 

10. Retention

Hier wird die Dauer definiert, wie lange ein Release im Azure DevOps gespeichert wird. Diese Feature ist sehr nützlich. Z.B.: es wird ein neues Release veröffentlicht und es kommt zu Problemen auf dem Produktivserver. Dann kann man einfach in das vorherige Release springen und dort die funktionstüchtige Version erneut veröffentlichen.

 

11. Options

Unter den Optionen kann am eine Beschreibung für das Release hinterlegen und ein Release-Format bestimmen. Dies dient der besseren Übersicht.

Bei den „Integrations“ kann der Release-Prozess mit einem Ticket verknüpft werden. Das hilft den Entwicklern zur besseren Kontrolle, ob ihr neues Feature bereits veröffentlicht wurde oder nicht.

12. History

Im Historien-Bereich können alle Änderungen am Release nachverfolgt werden. Hier wird gespeichert wer wann was geändert hat. Dies ist ein weiteres Kontrollinstrument, welches der Sicherheit und der Nachvollziehbarkeit dient.

Quellen

Dokumentation:

• https://docs.microsoft.com/de-de/azure/devops/?view=azure-devops

Quellen:

• https://en.wikipedia.org/wiki/DevOps
• https://docs.microsoft.com/en-us/azure/devops/boards/get-started/plan-track-work?view=azure-devops&tabs=agile-process (Zuletzt Abgerufen: 19.12.2021)
• https://docs.microsoft.com/en-us/azure/devops/boards/sprints/scrum-overview?view=azure-devops (Zuletzt Abgerufen: 19.12.2021)

Bildquellen:

• https://docs.microsoft.com/en-us/azure/devops/boards/get-started/plan-track-work?view=azure-devops&tabs=agile-process (Zuletzt Abgerufen: 19.12.2021)