https://thedotnetblog.com/de/tags/devsecops/Articles, tutorials and insights from the .NET community.Hugode@thedotnetblog (The .NET Blog)@thedotnetblogWed, 15 Jul 2026 00:00:00 +0000https://thedotnetblog.com/de/news/emiliano-montesdeoca/azure-devops-sql-projects-ci-cd-fundamentals/Wed, 15 Jul 2026 00:00:00 +0000Emiliano Montesdeocahttps://thedotnetblog.com/de/news/emiliano-montesdeoca/azure-devops-sql-projects-ci-cd-fundamentals/Das SQL-Projekte-Pipeline-Modell in Azure DevOps beweist, dass Datenbankbereitstellung wiederholbar, sicher und testbar sein kann, wenn Teams Code-first CI/CD-Disziplin annehmen.<p>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.</p> <p>Originalquelle: <a href="https://devblogs.microsoft.com/azure-sql/fundamentals-of-azure-devops-with-sql-projects/">https://devblogs.microsoft.com/azure-sql/fundamentals-of-azure-devops-with-sql-projects/</a></p> <p>Der stärkste Teil des Ansatzes ist nicht die YAML-Syntax, sondern die <strong>Disziplin-Reihenfolge</strong>: zuerst bauen, dann veröffentlichen und den Deployment-Pfad mit Least-Privilege und passwortloser Identität sichern. Das Bauen einer <code>.sqlproj</code> mit <code>dotnet build</code> validiert frühzeitig die Zielplattform-Kompatibilität und produziert ein DACPAC-Artefakt, das durch Umgebungen gefördert werden kann.</p> <p>Meine Ansicht ist klar: <strong>Wenn Ihr Schema nicht in CI gebaut wird, ist Ihr Datenbankqualitätsprozess größtenteils Hoffnung</strong>. Lokaler Erfolg in SSMS oder VS Code ist keine Release-Garantie.</p> <p>Das Deployment-Design ist auch erfrischend <strong>pragmatisch</strong>. 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.</p> <h3 id="praktische-empfehlungen-zur-sofortigen-anwendung">Praktische Empfehlungen zur sofortigen Anwendung</h3> <ul> <li><strong>Teilen Sie Build- und Deploy-Pipelines auf.</strong> Der Build sollte bei Branches-Änderungen laufen und schnell fehlschlagen. Deploy sollte umgebungsspezifisch und policy-gesteuert sein.</li> <li><strong>Speichern Sie Zielverbindungszeichenfolgen</strong> und Infrastruktur-Metadaten in gesicherten Pipeline-Variablen und rotieren Sie regelmäßig Governance-Reviews für Rollenzuweisungen.</li> <li><strong>Halten Sie SqlPackage-Versionen explizit und fixiert in CI</strong>, um Überraschungen durch Verhaltensänderungen zu vermeiden.</li> </ul> <p><strong>Nicht zu früh überprivilegieren.</strong> Mit <code>db_ddladmin</code>, <code>db_datareader</code> und <code>db_datawriter</code> zu beginnen, ist eine bessere Baseline, als jedem Pipeline-Prinzipal <code>db_owner</code> zu geben, &ldquo;nur damit es funktioniert.&rdquo; Eskalieren Sie nur, wenn eine konkrete Deployment-Anforderung es als notwendig erweist.</p> <p>Originalquelle: <a href="https://devblogs.microsoft.com/azure-sql/fundamentals-of-azure-devops-with-sql-projects/">https://devblogs.microsoft.com/azure-sql/fundamentals-of-azure-devops-with-sql-projects/</a></p>