Azure DevOps

Azure DevOps ist die zentrale DevOps-Plattform von Microsoft, die wir am Standort Osnabrück für die gesamte Softwareentwicklung einsetzen. Sie bündelt Quellcodeverwaltung, Projektplanung, automatisierte Builds und Deployments in einer integrierten Umgebung.

1. Überblick

Azure DevOps besteht aus mehreren Diensten, von denen wir in Osnabrück die folgenden aktiv nutzen:

Dienst	Zweck	Genutzt in OsnabrückK
Azure Repos	Git-Quellcodeverwaltung	Ja – für alle Projekte
Azure Boards	Work Items, Sprints, Backlogs	Ja – für Aufgabenplanung
Azure Pipelines	CI/CD – Build & Deployment	Ja – für AL-Builds und Deployments
Azure Artifacts	NuGet / Package-Feed	Ja – für AL-Abhängigkeiten
Azure Test Plans	Manuelle und automatisierte Tests	Nein – aktuell nicht im Einsatz

Unser Azure DevOps-Portal ist unter folgender URL erreichbar:
https://dev.azure.com/katargo

2. Azure Repos – Quellcodeverwaltung

Azure Repos ist unser zentrales Git-Repository-System. Jedes Projekt in Osnabrück hat ein eigenes Repository innerhalb der Organisation katargo.

2.1 Repository klonen

# HTTPS
git clone https://katargo@dev.azure.com/katargo/<Projektname>/_git/<Reponame>

# SSH (empfohlen für lokale Entwicklung)
git clone git@ssh.dev.azure.com:v3/katargo/<Projektname>/<Reponame>

2.2 Branch-Strategie

Wir arbeiten mit einem Feature-Branch-Workflow. Details dazu sind in der GIT-Branching-Strategie beschrieben.

main – stabiler, produktionsnaher Stand
feature/* – Entwicklung neuer Funktionen
hotfix/* – dringende Fehlerbehebungen

Änderungen an main sind nur über Pull Requests erlaubt.

2.3 Pull Request Workflow

# 1. Feature Branch erstellen
git checkout -b feature/neue-funktion

# 2. Änderungen committen
git add .
git commit -m "feat: Neue Funktion implementiert"

# 3. Branch pushen
git push --set-upstream origin feature/neue-funktion

# 4. Pull Request im Azure DevOps Web-Interface erstellen
# 5. Code Review abwarten und Feedback einarbeiten
# 6. Nach Approval: Merge in Main-Branch

2.4 Commits mit Work Items verknüpfen

Commit-Messages können direkt mit Work Items verknüpft werden. Damit ist jede Änderung am Code einer Aufgabe oder einem Bug zugeordnet.

# Work Item referenzieren
git commit -m "feat: Filterfunktion erweitert #456"

# Work Item automatisch schließen
git commit -m "fix: Druckfehler behoben - fixes #999"

3. Azure Boards – Aufgabenplanung

Azure Boards nutzen wir in Osnabrück zur Planung und Nachverfolgung von Entwicklungsaufgaben. Wir arbeiten mit dem Scrum-Prozessmodell.

3.1 Work Item Typen

Typ	Beschreibung
Epic	Große übergeordnete Themen oder Projekte
Feature	Lieferbare Funktionalität innerhalb eines Epics
Product Backlog Item (PBI)	Konkrete Entwicklungsaufgabe
Bug	Gemeldeter Fehler
Task	Technische Unteraufgabe eines PBIs

3.2 Boards und Backlogs

Backlog: Übersicht aller offenen PBIs und Bugs, priorisiert nach Sprint
Sprint Board: Kanban-ähnliche Ansicht für den aktiven Sprint (To Do → In Progress → Done)
Queries: Gespeicherte Abfragen für eigene Ansichten (z. B. „Meine offenen Bugs")

3.3 Work Items im Alltag

Jede Entwicklungsaufgabe wird als PBI oder Task angelegt, bevor mit der Arbeit begonnen wird
Commits und Pull Requests werden mit dem zugehörigen Work Item verknüpft (siehe Abschnitt 2.4)
Der Status wird über das Sprint Board aktuell gehalten

4. Azure Pipelines – CI/CD

Azure Pipelines automatisieren bei uns den Build- und Deployment-Prozess für Business Central AL-Erweiterungen.

4.1 Aufbau

Unsere Pipelines sind als YAML-Dateien im jeweiligen Repository hinterlegt (Pipelines/build.yml, Pipelines/deploy.yml). Damit ist die Pipeline-Konfiguration versioniert und nachvollziehbar.

4.2 Build-Pipeline

Die Build-Pipeline läuft automatisch bei jedem Push auf einen Feature-Branch sowie bei jedem Pull Request gegen main. Sie:

kompiliert die AL-Erweiterung
führt AL-Code-Analysen durch (AppSourceCop, PerTenantExtensionCop)
erzeugt ein .app-Paket als Build-Artefakt

4.3 Deployment-Pipeline

Die Deployment-Pipeline überträgt ein fertig gebautes .app-Paket auf eine Zielumgebung (z. B. Sandbox oder Produktion). Sie wird manuell oder nach einem Merge in main ausgelöst.

4.4 Pipeline-Status

Der aktuelle Status jeder Pipeline ist im Azure DevOps Portal unter Pipelines sichtbar. Fehlgeschlagene Builds erzeugen automatisch eine Benachrichtigung an den Autor des Commits.

5. Azure Artifacts – Package Feed

Über Azure Artifacts stellen wir gemeinsam genutzte AL-Abhängigkeiten als NuGet-Pakete bereit. Unsere Pipelines laden diese Abhängigkeiten automatisch aus dem internen Feed herunter.

Der Feed ist unter folgender URL erreichbar und in den Projekten als Quelle konfiguriert:
https://pkgs.dev.azure.com/katargo/_packaging/<Feedname>/nuget/v3/index.json