https://thedotnetblog.com/ko/tags/sql-projects/Articles, tutorials and insights from the .NET community.Hugoko@thedotnetblog (The .NET Blog)@thedotnetblogWed, 15 Jul 2026 00:00:00 +0000https://thedotnetblog.com/ko/news/emiliano-montesdeoca/azure-devops-sql-projects-ci-cd-fundamentals/Wed, 15 Jul 2026 00:00:00 +0000Emiliano Montesdeocahttps://thedotnetblog.com/ko/news/emiliano-montesdeoca/azure-devops-sql-projects-ci-cd-fundamentals/Azure DevOps의 SQL 프로젝트 파이프라인 모델은 팀이 코드 우선 CI/CD 규율을 채택할 때 데이터베이스 전달이 반복 가능하고, 안전하며, 테스트 가능함을 증명합니다.<p>많은 팀이 DevOps를 한다고 주장하면서도 누군가의 노트북에서 데이터베이스 변경을 수동으로 배포합니다. 그 모순이 바로 이 Azure SQL 가이드가 해결하는 것입니다. SQL 프로젝트와 Azure DevOps 파이프라인은 데이터베이스 전달을 결정론적이고, 감사 가능하며, 실제 프로덕션 워크플로에 충분히 안전하게 만듭니다.</p> <p>원문: <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>이 접근법의 가장 강력한 부분은 YAML 구문이 아니라 <strong>규율 순서</strong>입니다: 먼저 빌드, 다음에 게시, 최소 권한과 비밀번호 없는 아이덴티티로 배포 경로를 보호합니다. <code>dotnet build</code>로 <code>.sqlproj</code>를 빌드하면 대상 플랫폼 호환성을 조기에 검증하고 환경을 통해 승격될 수 있는 DACPAC 아티팩트를 생성합니다.</p> <p>제 견해는 간단합니다: <strong>스키마가 CI에서 빌드되지 않는다면, 데이터베이스 품질 프로세스는 대부분 희망에 의존하는 것입니다.</strong> SSMS나 VS Code에서의 로컬 성공은 릴리스 보장이 아닙니다.</p> <p>배포 설계는 또한 상쾌할 정도로 <strong>실용적</strong>입니다. Entra 아이덴티티에 연결된 서비스 연결 사용, 스키마 및 데이터 비교를 위한 범위 제한 데이터베이스 역할 부여, 러너 IP에 대한 임시 방화벽 개방을 보장된 정리와 함께 자동화합니다. 이는 팀이 침해 검토가 모든 것을 재검토하도록 강제할 때까지 건너뛰는 운영 위생의 종류입니다.</p> <h3 id="즉시-적용할-실용적인-권장사항">즉시 적용할 실용적인 권장사항</h3> <ul> <li><strong>빌드와 배포 파이프라인을 분리</strong>하세요. 빌드는 브랜치 변경 시 실행되고 빠르게 실패해야 합니다. 배포는 환경별로 정책 게이트가 있어야 합니다.</li> <li><strong>대상 연결 문자열</strong>과 인프라 메타데이터를 보안 파이프라인 변수에 저장하고, 역할 할당에 대한 거버넌스 검토를 정기적으로 순환하세요.</li> <li><strong>CI에서 SqlPackage 버전을 명시적이고 고정</strong>하여 예상치 못한 동작 변경을 피하세요.</li> </ul> <p><strong>일찍 과도한 권한을 부여하지 마세요.</strong> <code>db_ddladmin</code>, <code>db_datareader</code>, <code>db_datawriter</code>로 시작하는 것이 모든 파이프라인 보안 주체에 <code>db_owner</code>를 주는 것보다 더 나은 기준입니다. 구체적인 배포 요구사항이 필요함을 증명할 때만 권한을 상향하세요.</p> <p>또 다른 강력한 시사점은 <strong>이식성</strong>입니다. SQL 프로젝트가 .NET SDK 툴체인에서 실행되기 때문에 이 패턴은 Azure DevOps 전용이 아닙니다. 동일한 기초가 GitHub Actions나 다른 오케스트레이터로도 전환되므로, 이 가이드는 전략적이며 플랫폼에 고정되지 않습니다.</p> <h2 id="결론">결론</h2> <p>조직이 여전히 스키마 전달을 앱 CI/CD 외부의 특별한 프로세스로 취급한다면, 이것이 마이그레이션 청사진입니다. 영웅적인 플랫폼 엔지니어링이 필요하지 않습니다. <strong>일관성, 아이덴티티 우선 보안</strong>, 그리고 임시 권한 경로를 통해 데이터베이스 변경을 배송하는 관행을 중단하려는 의지가 필요합니다.</p> <p>이를 수행하는 팀은 더 적은 롤백 이벤트로 더 빠르게 출시할 것입니다. 지연하는 팀은 수동 데이터 플레인 배포의 숨겨진 세금을 계속 지불할 것입니다.</p>