Viele Teams behaupten, sie machen DevOps, und deployen dann Datenbankänderungen manuell von einem Laptop. Dieser Widerspruch ist genau das, was diese Azure SQL-Anleitung behebt. SQL-Projekte plus Azure DevOps-Pipelines machen Datenbankbereitstellung deterministisch, auditierbar und sicher genug für echte Produktions-Workflows.
Originalquelle: https://devblogs.microsoft.com/azure-sql/fundamentals-of-azure-devops-with-sql-projects/
Der stärkste Teil des Ansatzes ist nicht die YAML-Syntax, sondern die Disziplin-Reihenfolge: zuerst bauen, dann veröffentlichen und den Deployment-Pfad mit Least-Privilege und passwortloser Identität sichern. Das Bauen einer .sqlproj mit dotnet build validiert frühzeitig die Zielplattform-Kompatibilität und produziert ein DACPAC-Artefakt, das durch Umgebungen gefördert werden kann.
Meine Ansicht ist klar: Wenn Ihr Schema nicht in CI gebaut wird, ist Ihr Datenbankqualitätsprozess größtenteils Hoffnung. Lokaler Erfolg in SSMS oder VS Code ist keine Release-Garantie.
Das Deployment-Design ist auch erfrischend pragmatisch. Verwenden Sie Service Connections, die an Entra-Identitäten gebunden sind, gewähren Sie Bereichs-Datenbankrollen für Schema- und Datenvergleich und automatisieren Sie temporäre Firewall-Öffnung für Runner-IPs mit garantierter Bereinigung. Das ist die Art von Betriebshygiene, die Teams überspringen, bis ein Sicherheitsvorfall sie zwingt, alles zu überdenken.
Praktische Empfehlungen zur sofortigen Anwendung
- Teilen Sie Build- und Deploy-Pipelines auf. Der Build sollte bei Branches-Änderungen laufen und schnell fehlschlagen. Deploy sollte umgebungsspezifisch und policy-gesteuert sein.
- Speichern Sie Zielverbindungszeichenfolgen und Infrastruktur-Metadaten in gesicherten Pipeline-Variablen und rotieren Sie regelmäßig Governance-Reviews für Rollenzuweisungen.
- Halten Sie SqlPackage-Versionen explizit und fixiert in CI, um Überraschungen durch Verhaltensänderungen zu vermeiden.
Nicht zu früh überprivilegieren. Mit db_ddladmin, db_datareader und db_datawriter zu beginnen, ist eine bessere Baseline, als jedem Pipeline-Prinzipal db_owner zu geben, “nur damit es funktioniert.” Eskalieren Sie nur, wenn eine konkrete Deployment-Anforderung es als notwendig erweist.
Originalquelle: https://devblogs.microsoft.com/azure-sql/fundamentals-of-azure-devops-with-sql-projects/
