테스트에서 라이브로 SQL Server 데이터베이스 배포

08-06-2019
|

문제

두 대의 SQL Server, 특히 SQL Server 2005 간의 데이터베이스 배포를 어떻게 관리하는지 궁금합니다.이제 개발과 라이브가 있습니다.이는 빌드 스크립트(표준 Windows 배치, 해당 스크립트의 현재 복잡도와 관련하여 나중에 PowerShell 등으로 전환할 수 있음)의 일부여야 하므로 Enterprise Manager/Management Studio Express는 포함되지 않습니다.

.mdf 파일을 복사해서 첨부하시겠습니까?나는 바이너리 데이터로 작업할 때 항상 약간 조심합니다. 이는 호환성 문제인 것 같습니다(개발 및 라이브는 항상 동일한 버전의 서버를 실행해야 하지만).

아니면 T-SQL에 "EXPLAIN CREATE TABLE"이 없기 때문에 기존 데이터베이스를 대상 서버에서 실행할 수 있는 SQL 스크립트로 내보내는 작업을 수행합니까?그렇다면 특정 데이터베이스를 SQL 쿼리로 자동 덤프하고 명령줄에서 실행하는 도구가 있습니까?(다시 말하지만 Enterprise Manager/Management Studio Express는 포함되지 않습니다.)

마지막으로, 라이브 데이터베이스에 이미 데이터가 포함되어 있다는 점을 감안할 때 배포에는 모든 테이블을 생성하는 것이 아니라 구조의 차이를 확인하고 대신 라이브 데이터베이스의 ALTER TABLE을 확인하는 작업이 포함될 수 있으며, 기존 필드가 변경될 때 데이터 확인/변환이 필요할 수도 있습니다.

이제 나는 그것에 대해 좋은 소식을 많이 듣습니다. 레드 게이트 제품이지만 취미 프로젝트의 경우 가격이 약간 가파르습니다.

그렇다면 테스트에서 라이브로 SQL Server 데이터베이스를 자동으로 배포하기 위해 무엇을 사용하고 있습니까?

해결책

나는 모든 DDL(생성/변경/삭제) 문을 직접 코딩하여 .sln에 텍스트 파일로 추가하고 일반 버전 관리(Subversion을 사용하지만 모든 개정 제어가 작동해야 함)를 사용했습니다.이렇게 하면 버전 관리의 이점을 얻을 수 있을 뿐만 아니라 개발/단계에서 라이브로 업데이트하는 것은 코드와 데이터베이스에 대해 동일한 프로세스입니다. 즉, 태그, 분기 등이 모두 동일하게 작동합니다.

그렇지 않으면 redgate를 구매하는 회사가 없으면 redgate가 비싸다는 데 동의합니다.그래도 회사에서 구입해 줄 수 있다면 정말 그만한 가치가 있습니다!

다른 팁

내 프로젝트에서는 REd Gate의 SQL Compare와 무료로 다운로드할 수 있는 Microsoft의 Database Publishing Wizard를 번갈아 사용합니다.여기.

마법사는 SQL 비교 또는 SQL 데이터 비교만큼 매끄럽지는 않지만 트릭을 수행합니다.한 가지 문제는 생성된 스크립트가 한 번에 흐르도록 재배열 및/또는 편집이 필요할 수 있다는 것입니다.

좋은 점은 무료 도구로서는 나쁘지 않은 스키마와 데이터를 이동할 수 있다는 것입니다.

문제에 대한 Microsoft의 솔루션을 잊지 마십시오. Visual Studio 2008 데이터베이스 에디션.데이터베이스에 변경 사항을 배포하고, 스키마 및/또는 데이터 변경 사항에 대한 데이터베이스 간의 차이점을 생성하고, 단위 테스트, 테스트 데이터 생성을 위한 도구가 포함되어 있습니다.

꽤 비싸지만 체험판을 한동안 사용해 봤는데 정말 훌륭하다고 생각했어요.이는 다른 코드 조각처럼 데이터베이스 작업을 쉽게 만듭니다.

Rob Allen과 마찬가지로 Redgate의 SQL 비교/데이터 비교를 사용합니다.또한 Microsoft의 데이터베이스 게시 마법사도 사용합니다.또한 SQL 스크립트를 가져와 서버에서 실행하는 C#으로 작성한 콘솔 앱도 있습니다.이렇게 하면 명령줄이나 배치 스크립트에서 'GO' 명령이 포함된 대규모 스크립트를 실행할 수 있습니다.

콘솔 응용 프로그램에서는 Microsoft.SqlServer.BatchParser.dll 및 Microsoft.SqlServer.ConnectionInfo.dll 라이브러리를 사용합니다.

나는 소스 제어에 보관하는 텍스트 파일에 테이블을 생성하고 변경하기 위한 모든 SQL 스크립트를 유지함으로써 Karl과 동일한 방식으로 작업합니다.실제로 실행할 ALTER를 결정하기 위해 스크립트가 라이브 데이터베이스를 검사해야 하는 문제를 피하기 위해 일반적으로 다음과 같이 작업합니다.

첫 번째 버전에서는 테스트하는 동안 모든 것을 하나의 SQL 스크립트에 배치하고 모든 테이블을 CREATE로 처리했습니다.즉, 테스트 중에 테이블을 많이 삭제하고 읽게 되지만 프로젝트 초기에는 큰 문제가 되지 않습니다(어쨌든 일반적으로 그 시점에서 사용하는 데이터를 해킹하기 때문입니다).
모든 후속 버전에서는 다음 두 가지 작업을 수행합니다.해당 버전에 대한 ALTER만 포함하는 업그레이드 SQL 스크립트를 보관할 새 텍스트 파일을 만듭니다.그리고 원본을 변경하고 새로운 데이터베이스 스크립트도 만듭니다.이렇게 하면 업그레이드가 업그레이드 스크립트만 실행하지만, DB를 다시 생성해야 하는 경우 거기에 도달하기 위해 100개의 스크립트를 실행할 필요가 없습니다.
DB 변경 사항을 어떻게 배포하는지에 따라 일반적으로 DB 버전을 보유하는 DB에 버전 테이블도 넣습니다.그런 다음 어떤 스크립트를 실행할지 사람이 결정하는 대신 생성/업그레이드 스크립트를 실행하는 코드가 무엇이든 버전을 사용하여 실행할 항목을 결정합니다.

이것이 하지 않을 한 가지는 테스트에서 프로덕션으로 이동하는 것의 일부가 데이터인 경우 도움이 되지만, 구조를 관리하고 훌륭하지만 값비싼 DB 관리 패키지에 대한 비용을 지불하지 않으려는 경우에는 실제로 그리 어렵지 않습니다.나는 또한 이것이 DB를 정신적으로 추적하는 매우 좋은 방법이라는 것을 알았습니다.

구매하는 회사가 있는 경우 Quest Software의 Toad에는 이러한 종류의 관리 기능이 내장되어 있습니다.두 스키마를 비교하고 한 스키마에서 다른 스키마로 동기화 스크립트를 생성하는 것은 기본적으로 두 번의 클릭 작업입니다.

물론 SQL Server를 포함하여 대부분의 인기 있는 데이터베이스에 대한 버전이 있습니다.

나는 모든 것을 스크립팅하는 것이 최선의 방법이며 직장에서 옹호하는 것이라는 점에 동의합니다.DB 및 객체 생성부터 조회 테이블 채우기까지 모든 것을 스크립팅해야 합니다.

UI에서만 수행하는 모든 작업은 번역되지 않습니다(특히 변경 사항의 경우...).첫 번째 배포에는 그다지 많지 않음) 결국 Redgate가 제공하는 것과 같은 도구가 필요하게 됩니다.

SMO/DMO를 사용하면 스키마 스크립트를 생성하는 것이 그리 어렵지 않습니다.데이터는 좀 더 재미있지만 여전히 실행 가능합니다.

일반적으로 저는 "Script It" 접근 방식을 취하지만 다음과 같은 사항을 고려해 볼 수도 있습니다.

데이터 하위 집합으로 개발할 수 있도록 개발과 준비를 구별합니다.이를 통해 일부 프로덕션 데이터를 간단히 가져오거나 보안과 관련된 가짜 데이터를 생성하는 도구를 만들 것입니다.
팀 개발을 위해 데이터베이스에 대한 각 변경 사항은 팀 구성원 간에 조정되어야 합니다.스키마와 데이터 변경은 혼합될 수 있지만 단일 스크립트로 특정 기능을 활성화해야 합니다.모든 기능이 준비되면 이를 단일 SQL 파일로 묶고 프로덕션 복원에 대해 실행합니다.
스테이징이 승인되면 프로덕션 머신에서 단일 SQL 파일을 다시 실행합니다.

저는 Red Gate 도구를 사용해 보았는데요. 엄청난 하지만 여유가 없다면 도구를 만들고 이런 방식으로 작업하는 것이 이상적이지 않습니다.

나는 Subsonic의 마이그레이션 메커니즘을 사용하고 있으므로 위쪽과 아래쪽의 2가지 메서드가 있는 순차 순서로 클래스가 있는 dll이 있습니다.Nant에는 지속적인 통합/빌드 스크립트 후크가 있으므로 데이터베이스 업그레이드를 자동화할 수 있습니다.

세계 최고의 것은 아니지만 DDL을 작성하는 것보다 낫습니다.

RedGate Sql비교 내 생각에는 갈 수 있는 방법이다.우리는 정기적으로 DB 배포를 수행하고 있으며 해당 도구를 사용하기 시작한 이후로 뒤돌아본 적이 없습니다.매우 직관적인 인터페이스로 결국 많은 시간을 절약할 수 있습니다.

Pro 버전은 소스 제어 통합을 위한 스크립팅도 처리합니다.

또한 모든 개체와 데이터에 대한 스크립트를 유지 관리합니다.배포를 위해 나는 이 무료 유틸리티를 작성했습니다. http://www.sqldart.com.이를 통해 스크립트 파일을 재정렬하고 트랜잭션 내에서 전체 작업을 실행할 수 있습니다.

모든 것을 소스 제어에 유지하고 모든 변경 사항을 수동으로 스크립팅하는 데 동의합니다.단일 릴리스에 대한 스키마 변경 사항은 해당 릴리스용으로 특별히 생성된 스크립트 파일로 이동됩니다.저장된 모든 프로세스, 뷰 등은 개별 파일로 이동해야 하며 소스 제어가 진행되는 한 .cs 또는 .aspx처럼 처리되어야 합니다.나는 프로그래밍 기능 업데이트를 위해 하나의 큰 .sql 파일을 생성하기 위해 powershell 스크립트를 사용합니다.

나는 새 테이블, 새 열 등과 같은 스키마 변경 사항을 자동으로 적용하는 것을 좋아하지 않습니다.프로덕션 릴리스를 수행할 때 각 명령이 예상대로 작동하는지 확인하기 위해 스크립트 변경 명령을 명령별로 진행하는 것을 좋아합니다.프로덕션 환경에서 대규모 변경 스크립트를 실행하다가 개발 단계에서 나타나지 않은 작은 세부 사항을 잊어버렸기 때문에 오류가 발생하는 것보다 더 나쁜 것은 없습니다.

또한 인덱스를 코드 파일처럼 처리하고 소스 제어에 넣어야 한다는 것도 배웠습니다.

그리고 개발 데이터베이스와 라이브 데이터베이스가 2개 이상 있어야 합니다.모든 사람이 일상적인 개발 작업에 사용하는 개발 데이터베이스가 있어야 합니다.그런 다음 프로덕션을 모방하고 통합 테스트를 수행하는 데 사용되는 스테이징 데이터베이스입니다.그런 다음 가능한 경우 전체 최신 프로덕션 복사본(전체 백업에서 복원)을 사용할 수 있으므로 마지막 설치 테스트는 가능한 한 실제에 가까운 항목에 대해 수행됩니다.

모든 데이터베이스 생성을 DDL로 수행한 다음 해당 DDL을 스키마 유지 관리 클래스로 래핑합니다.처음에는 DDL을 생성하기 위해 다양한 작업을 수행할 수 있지만 기본적으로 모든 스키마 유지 관리는 코드에서 수행됩니다.이는 또한 SQL에 잘 매핑되지 않는 DDL이 아닌 작업을 수행해야 하는 경우 절차적 논리를 작성하고 DDL/DML 덩어리 사이에서 실행할 수 있음을 의미합니다.

내 DB에는 현재 버전을 정의하는 테이블이 있으므로 상대적으로 간단한 테스트 세트를 코딩할 수 있습니다.

DB가 존재하나요?그렇지 않은 경우 생성하십시오.
DB가 현재 버전인가요?그렇지 않은 경우 스키마를 최신 상태로 유지하는 메서드를 순서대로 실행합니다(이 시점에서 사용자에게 확인하고 이상적으로는 백업을 수행하라는 메시지를 표시할 수 있습니다).

단일 사용자 앱의 경우 이 기능을 실행하고, 웹 앱의 경우 현재 버전이 일치하지 않으면 사용자를 잠그고 독립 실행형 스키마 관리 앱을 실행합니다.다중 사용자의 경우 특정 환경에 따라 달라집니다.

장점?글쎄요, 저는 이 방법론을 사용하는 앱의 스키마가 해당 애플리케이션의 모든 인스턴스에서 일관적이라는 매우 높은 수준의 확신을 갖고 있습니다.완벽하지는 않고 문제도 있지만 작동합니다...

팀 환경에서 개발할 때 몇 가지 문제가 있지만 어쨌든 그것은 어느 정도 주어진 것입니다!

머프

나는 현재 당신과 같은 일을 하고 있습니다.SQL Server 데이터베이스를 테스트부터 라이브까지 배포할 뿐만 아니라 로컬 -> 통합 -> 테스트 -> 프로덕션의 전체 프로세스를 포함합니다.그러니 매일 나를 쉽게 만들 수 있는 건 I do Red-Gate SQL 비교를 사용한 NAnt 작업.저는 RedGate에서 일하고 있지 않지만 그것이 좋은 선택이라고 말하고 싶습니다.

라이센스 : CC-BY-SA ~와 함께 속성

제휴하지 않습니다 StackOverflow