Optional vorab: Allgemeiner Überblick über DevOps-Konzepte
Optional vorab: Allgemeiner Überblick über die Funktionen von Azure DevOps (TFS)
DevOps-Strategie und -Konzepte
- Continuous Integration
- Continuous Delivery und Continuous Deployment
- Pipelines as Code: Warum YAML heute der Standard ist
- "Build once, deploy many": ein Artefakt durch alle Umgebungen
Build Pipelines (YAML)
- Aufbau einer YAML-Pipeline: Stages, Jobs, Steps
- Tasks und Skripte (PowerShell, Bash)
- Trigger: CI, Pfad- und Branchfilter, Pull Requests, Zeitpläne, Abhängigkeiten zwischen Pipelines
- Variablen, Parameter und Ausdrücke (Auswertung zur Compile-Zeit vs. zur Laufzeit)
- Agents: Microsoft-hosted Agents (Linux, Windows, macOS, auch ARM64), Self-hosted Agents, Managed DevOps Pools (nur Services)
- Agent-Pools, Capabilities und Demands
- Caching und Build-Performance
- Ausgabeartefakte: Pipeline Artifacts (nur Services) und Build Artifacts
- Versionierung: Build-Nummer, Semantic Versioning (SemVer), z. B. mit Nerdbank.GitVersioning
- Änderungsverfolgung: Commits und Work Items im Build
- Builds starten und überwachen, Fehlersuche im Pipeline-Log
- Benachrichtigungen
Wiederverwendung
- Templates für Steps, Jobs, Stages und Variablen
- extends-Templates als verbindlicher Rahmen
- Zentrale Template-Repositories mit Versionierung
- Templates (Nachfolger der Task Groups aus Classic-Pipelines) - inkl. Umstieg
- Tasks und Erweiterungen aus dem Marketplace
Build Tasks
- Build für .NET (dotnet.exe) und .NET Framework (MSBuild.exe)
- optional Build für andere Plattformen (z. B. Webframeworks wie Angular, React oder Vue.js, Java, Node.js, Python)
- Container-Images bauen (Docker) und in eine Registry übertragen
- Durchführung von Unit Tests, Testergebnisse und Code Coverage
- Statische Codeanalyse (z. B. Roslyn-Analyzer, SonarQube/SonarCloud)
Qualitäts- und Security-Gates
- Branch Policies und Build Validation für Pull Requests
- Coverage-Schwellen und Mindestanzahl von Tests
- Secret-Scanning (z. B. Gitleaks, GitHub Secret Protection for Azure DevOps (nur Services))
- Prüfung von Abhängigkeiten auf Schwachstellen (z. B. GitHub Code Security for Azure DevOps (nur Services), OWASP Dependency-Check)
- Sicherheitsanalyse des Quellcodes mit CodeQL (GitHub Code Security for Azure DevOps, nur Services), optional mit KI-gestützten Korrekturvorschlägen (Copilot Autofix)
- Container-Images auf Schwachstellen prüfen (z. B. Trivy, Microsoft Defender for Cloud)
- Fail-Policies: Wann blockiert die Pipeline, wann warnt sie nur?
Software Supply Chain Security
- Software Bill of Materials (SBOM) erzeugen (CycloneDX, SPDX)
- Artefakte und Container-Images signieren (z. B. Notation, cosign)
- Herkunftsnachweise für Artefakte (SLSA-Provenance)
- Regulatorische Anforderungen als Treiber: EU Cyber Resilience Act, NIS2, DORA-Verordnung für den Finanzsektor
Variablen und Sicherheit
- Pipeline-Berechtigungen und Least Privilege
- Service Connections mit Workload Identity Federation statt gespeicherter Secrets
- Variable Groups, geheime Variablen, Secure Files und Azure Key Vault
- Microsoft-Entra-Tokens (Nachfolger der Personal Access Tokens, PAT) - inkl. Umstieg
Multi-Stage-Pipelines und Release (YAML)
- Stages für Test, Staging und Produktion
- Deployment-Jobs und Deployment-Strategien (runOnce, rolling, canary)
- Environments mit Ressourcen (virtuelle Maschinen, Kubernetes)
- Validierung, Checks und Approvals: manuelle Freigabe, Branch Control, Business Hours, Invoke REST API
- Releases starten und überwachen, Re-Deploy und Rollback
- Rückverfolgbarkeit von Releases zu Quellcode und Work Items
- Benachrichtigungen
Infrastructure as Code in der Pipeline
- Terraform bzw. OpenTofu: plan als Vorschau im Pull Request, apply nach Freigabe, State sicher ablegen
- Alternativ Bicep bzw. ARM-Templates mit what-if und Deployment Stacks
- Infrastruktur und Anwendung im selben Ablauf, mit Workload Identity Federation statt gespeicherter Secrets
Progressive Delivery und Betrieb
- Deployment-Strategien: Blue-Green, Canary, Ring-Deployments und ein schneller Hotfix-Pfad
- Feature Flags (z. B. Azure App Configuration, OpenFeature, LaunchDarkly)
- Kurzlebige Umgebungen pro Pull Request
- Überwachung nach dem Deployment: Application Insights, OpenTelemetry, Release-Annotationen
Artefakte und Pakete
- Azure Artifacts: Feeds für NuGet, npm, Maven und Python, Upstream-Quellen
- Optional: Anbindung von Artifact-Repositories wie JFrog Artifactory
- Retention: Wie lange Builds, Artefakte und Pakete aufbewahrt werden
Release Tasks
- Integrationstests
- Lasttests mit Azure Load Testing (Nachfolger der Cloud-Lasttests in Azure DevOps und der Visual Studio Load Tests) - inkl. Umstieg bestehender Tests; alternativ JMeter, k6 oder Locust
- UI-Tests (z. B. Playwright, Selenium, FlaUI, Ranorex)
Deployment-Ziele
- Deployment in die Cloud (z. B. Azure App Service mit Deployment Slots und Swap, Azure Functions, Azure Container Apps mit Revisionen und Traffic-Splitting, Kubernetes/AKS mit Helm oder Kustomize; andere Clouds auf Anfrage)
- In-House-Deployments/On Premise Deployments über Self-hosted Agents
- Deployment auf Webserver (z. B. IIS, nginx, Apache)
- Deployment von Windows-Diensten
- Deployment auf Netzwerklaufwerke
- Desktop-Deployment per MSIX oder ClickOnce
- Erstellung eines Setups (z. B. MSIX, MSI mit WiX, Inno Setup) inkl. Code-Signierung
- Datenbank-Deployments (z. B. SQL Server mit DACPAC, Migrationen mit Entity Framework)
- Optional: Zusammenspiel mit verbreiteten Deployment-Werkzeugen, z. B. Argo CD oder Flux (GitOps für Kubernetes), Octopus Deploy oder Harness - je nachdem, was bei Ihnen im Einsatz ist
Bestehende Classic-Pipelines und Migration nach YAML
- Das JSON-basierte Classic-Build-System (seit 2015) und Classic Release Pipelines im Vergleich zu YAML
- Classic Release: Eingabeartefakte, Stages, Deployment Groups, Pre- und Post-Deployment-Approvals, Gates
- Gegenüberstellung Classic und YAML: Task Groups und Templates, Deployment Groups und Environments, Release-Variablen und Variable Groups
- Import und Export von Classic-Definitionen
- Schrittweise Migration des Bestands nach YAML
Optional: Ausblick auf andere CI/CD-Plattformen
- Azure Pipelines zusammen mit GitHub-Repositories (Hybridbetrieb)
- Vergleich und Migrationspfade zu GitHub Actions und GitLab CI
Optional: Vorbereitung auf die Zertifizierung AZ-400 (Microsoft Certified: DevOps Engineer Expert)
Optional: Einsatz von KI in Azure DevOps-Pipelines mit dem KI-Werkzeug nach Ihrer Wahl (z. B. GitHub Copilot, Claude Code (Anthropic), Codex (OpenAI), Cursor, Windsurf)
- YAML-Pipelines mit KI erstellen, erklären und migrieren (z. B. Classic nach YAML)
- Fehleranalyse von Pipeline-Läufen mit KI
- Automatisierte Qualitätssicherung mit KI, z. B. KI-gestützte Code-Reviews in Pull Requests (u. a. Copilot Code Review für Azure Repos, nur Services)
- KI-Agenten als Schritt in der Pipeline ausführen (z. B. GitHub Copilot, Claude Code im Headless-Modus, Codex)
- Anbindung von KI-Werkzeugen über die Azure DevOps REST API und den Azure DevOps MCP Server (nur Services)
- KI-Agenten in der Pipeline absichern: Prompt Injection über Pull Requests und Work Items, keine Secrets im Agent-Job, minimale Rechte, Freigabe vor privilegierten Läufen
- Sicherheit und Governance: Welche Daten verlassen das Haus? Rechte von KI-Agenten begrenzen
- Praktische Übungen mit dem ausgewählten KI-Werkzeug
Praxisszenarien:
- WebAPI-Backend (ASP.NET Core WebAPI mit SQL Server-Datenbank): Deployment auf Webserver und SQL Server mit Unit Tests, DB-Integrationstests und WebAPI-Integrationstests
- Web-Frontend (HTML-Anwendung mit Angular/React/Vue.js etc.): Deployment auf Webserver oder in die Cloud mit Unit Tests und Web-UI-Tests (z. B. Playwright)
- Desktop-Anwendung (WPF, Windows Forms oder WinUI 3): Deployment auf Netzlaufwerk und per ClickOnce oder MSIX mit Unit Tests und UI-Tests
- Desktop-Anwendung (WPF, Windows Forms oder WinUI 3): Deployment per Setup (MSIX oder MSI) inkl. Code-Signierung
- Container-basierte Web-API: Docker-Image bauen, in eine Registry übertragen und in die Cloud ausrollen (z. B. Azure Container Apps oder Kubernetes)
- On-Premise-Deployment auf Windows Server (IIS-Webanwendung oder Windows-Dienst) über Self-hosted Agents mit Freigaben, Health-Check und Rollback
- Migration einer bestehenden Classic-Build- und Release-Pipeline nach YAML
- Cloud-native End-to-End: Infrastruktur per Terraform (alternativ Bicep), Deployment einer Container-App oder nach AKS, Freischaltung per Feature Flag und Überwachung mit Application Insights
Optional:
- Weitere Datenbankarten auf Anfrage
- Weitere Szenarien auf Anfrage
- Arbeit an Ihren eigenen Pipelines