https://thedotnetblog.com/tags/ci/cd/Articles, tutorials and insights from the .NET community.Hugoen@thedotnetblog (The .NET Blog)@thedotnetblogWed, 15 Jul 2026 00:00:00 +0000https://thedotnetblog.com/news/emiliano-montesdeoca/azure-devops-sql-projects-ci-cd-fundamentals/Wed, 15 Jul 2026 00:00:00 +0000Emiliano Montesdeocahttps://thedotnetblog.com/news/emiliano-montesdeoca/azure-devops-sql-projects-ci-cd-fundamentals/The SQL projects pipeline model in Azure DevOps proves database delivery can be repeatable, secure, and testable when teams adopt code-first CI/CD discipline.<p>A lot of teams claim they do DevOps, then deploy database changes manually from someone’s laptop. That contradiction is exactly what this Azure SQL guidance fixes. SQL projects plus Azure DevOps pipelines make database delivery deterministic, auditable, and secure enough for real production workflows.</p> <p>Original source: <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>The strongest part of the approach is not the YAML syntax, it is the <strong>discipline sequence</strong>: build first, publish second, and secure the deployment path with least privilege and passwordless identity. Building a <code>.sqlproj</code> with <code>dotnet build</code> validates target-platform compatibility early and produces a DACPAC artifact that can be promoted through environments.</p> <p>My view is straightforward: <strong>if your schema is not built in CI, your database quality process is mostly hope</strong>. Local success in SSMS or VS Code is not a release guarantee.</p> <p>The deployment design is also refreshingly <strong>pragmatic</strong>. Use service connections tied to Entra identities, grant scoped database roles for schema and data comparison, and automate temporary firewall opening for runner IPs with guaranteed cleanup. This is the kind of operational hygiene teams skip until a breach review forces them to revisit everything.</p> <h3 id="practical-recommendations-to-apply-immediately">Practical recommendations to apply immediately</h3> <ul> <li><strong>Split build and deploy pipelines.</strong> Build should run on branch changes and fail fast. Deploy should be environment-specific and policy-gated.</li> <li><strong>Store target connection strings</strong> and infrastructure metadata in secured pipeline variables, and rotate governance reviews for role assignments regularly.</li> <li><strong>Keep SqlPackage versions explicit and pinned in CI</strong> to avoid surprise behavior shifts.</li> </ul> <p><strong>Do not over-privilege early.</strong> Starting with <code>db_ddladmin</code>, <code>db_datareader</code>, and <code>db_datawriter</code> is a better baseline than handing <code>db_owner</code> to every pipeline principal &ldquo;just to make it work.&rdquo; Escalate only when a concrete deployment requirement proves it is necessary.</p> <p>Another strong takeaway is <strong>portability</strong>. Because SQL projects run on the .NET SDK toolchain, this pattern is not Azure DevOps-only. The same fundamentals translate to GitHub Actions or other orchestrators, which makes this guidance strategic, not platform-locked.</p> <h2 id="the-bottom-line">The bottom line</h2> <p>If your organization still treats schema delivery as a special process outside app CI/CD, this is your migration blueprint. You do not need heroic platform engineering. You need <strong>consistency, identity-first security</strong>, and a willingness to stop shipping database changes through ad hoc privilege paths.</p> <p>The teams that do this will ship faster with fewer rollback events. The teams that delay will keep paying the hidden tax of manual data-plane deployments.</p>