데이터베이스 배포 전략(SQL Server)

데이터베이스 배포 전략(SQL Server)

매일 배포를 수행하고 데이터베이스 스크립트를 릴리스에 맞게 유지할 수 있는 방법을 찾고 있습니다.

현재 우리는 소스를 배포하는 상당히 괜찮은 방법을 가지고 있고, 단위 코드 적용 범위, 지속적인 통합 및 롤백 절차를 가지고 있습니다.

문제는 데이터베이스 스크립트를 릴리스에 맞게 유지하는 것입니다.모든 사용자가 테스트 데이터베이스에서 스크립트를 실행한 다음 라이브로 실행하는 것 같습니다. ORM 매핑이 업데이트되면(즉, 변경 사항이 라이브로 실행됨) 새 열이 선택됩니다.

첫 번째 문제는 스크립트 중 어느 것도 어디에도 작성할 필요가 없다는 것입니다. 일반적으로 모든 사람들이 Subversion 폴더에 스크립트를 넣으려고 "시도하지만" 더 게으른 사람들 중 일부는 라이브로 스크립트를 실행할 뿐이며 대부분의 경우 누가 데이터베이스에 무엇을 했는지 아무도 모릅니다.

두 번째 문제는 4개의 테스트 데이터베이스가 있는데 이 데이터베이스들이 항상 정상적이지 않다는 것입니다. 이 데이터베이스들을 진정으로 백업할 수 있는 유일한 방법은 라이브 데이터베이스에서 복원하는 것입니다.

이와 같은 프로세스는 개발자를 방해하는 것이 아니라 개발자를 돕기 위해 간단하고, 간단하고, 사용하기 쉬운 것이 필요하다고 저는 생각합니다.

제가 찾고 있는 것은 개발자가 데이터베이스 스크립트를 쉽게 기록하여 릴리스 절차의 일부로 실행할 수 있도록 하는 기술/아이디어입니다.개발자가 따르고자 하는 프로세스.

어떤 이야기나 사용 사례, 심지어 링크라도 도움이 될 것입니다.

바로 이 문제 때문에 마이그레이션 도구인 Migatordotnet을 사용하기로 결정했습니다.

마이그레이션(모든 도구에서)을 사용하면 변경사항을 수행하고 실행 취소하는 데 사용되는 간단한 클래스가 있습니다.예는 다음과 같습니다.

[Migration(62)]
public class _62_add_date_created_column : Migration
{
    public void Up()
    {
       //add it nullable
       Database.AddColumn("Customers", new Column("DateCreated", DateTime) );

       //seed it with data
       Database.Execute("update Customers set DateCreated = getdate()");

       //add not-null constraint
       Database.AddNotNullConstraint("Customers", "DateCreated");
    }

    public void Down()
    {
       Database.RemoveColumn("Customers", "DateCreated");
    }
}

이 예에서는 기존 데이터가 있는 테이블에 null이 아닌 새 열을 추가하는 것과 같이 변동성이 큰 업데이트를 처리하는 방법을 보여 줍니다.이를 쉽게 자동화할 수 있으며 버전 간에 쉽게 오르내릴 수 있습니다.

이것은 우리의 구축에 정말 귀중한 추가 요소가 되었고, 프로세스를 엄청나게 간소화했습니다.

에 다양한 마이그레이션 프레임워크를 비교하여 게시했습니다.NET 여기: http://benscheirman.com/2008/06/net-database-migration-tool-roundup

데이터베이스 버전 관리에 대한 K.Scott Allen의 일련의 게시물을 읽어 보십시오.
우리는 그가 설명한 기술을 바탕으로 데이터베이스 스크립트를 통제된 방식으로 적용하기 위한 도구를 개발했고 그것은 잘 작동합니다.
그런 다음 데이터베이스 업그레이드 스크립트를 보관하는 URL에 커밋을 수행할 때 각 테스트 데이터베이스에 변경사항이 배포되는 지속적인 통합 프로세스의 일부로 사용할 수 있습니다.기본 스크립트와 업그레이드 스크립트를 사용하여 항상 일련의 스크립트를 실행하여 데이터베이스를 현재 버전에서 필요한 새 상태로 가져올 수 있도록 하는 것이 좋습니다.
그러나 이를 위해서는 개발자들의 몇 가지 프로세스와 규율이 여전히 필요합니다(모든 변경 사항은 새 버전의 기본 설치 스크립트와 패치 스크립트로 롤롤해야 함).

몇 년 전부터 RedGate의 SQL Compare를 사용해 왔습니다.

http://www.red-gate.com/products/index.htm

Pro 버전에는 배포 절차를 설정하는 데 사용할 수 있는 명령줄 인터페이스가 있습니다.

우리는 K가 설명한 데이터베이스 버전의 수정된 버전을 사용합니다. 스캇 알렌.데이터베이스 게시 마법사를 사용하여 원래 기준 스크립트를 생성합니다.그런 다음 SQL SMO를 기반으로 저장된 프로시저, 뷰 및 사용자 기능을 덤프하는 맞춤형 C# 도구.스키마 및 데이터 변경 내용이 포함된 변경 스크립트는 Red Gate 도구를 통해 생성됩니다.그래서 우리는 결국 다음과 같은 구조를 갖게 됩니다.

Database\
    ObjectScripts\ - contains stored procs, views and user funcs 1-per file
    \baseline.sql - database snapshot which includes tables and data
    \sc.01.00.0001.sql - incremental change scripts
    \sc.01.00.0002.sql
    \sc.01.00.0003.sql

필요한 경우 사용자 지정 도구가 데이터베이스를 생성하고 기준선을 적용합니다.sql 필요한 경우 SchemaChanges 테이블을 추가하고 SchemaChanges 테이블에 있는 내용을 기준으로 필요에 따라 변경 스크립트를 적용합니다.이 프로세스는 cc.net 을 통해 배포 빌드를 수행할 때마다 앤트 빌드 스크립트의 일부로 수행됩니다.

schemachchanger 앱에 소스 코드를 원하는 사람이 있다면 codeplex/google 또는 어디에서나 올려놓을 수 있습니다.

데이터베이스 스키마를 동기화할 수 있도록 하려면 Red Gate SQL Comparison SDK를 사용해 보십시오. 생성 스크립트(newDb)를 기반으로 임시 데이터베이스를 구축합니다. 데이터베이스의 모양은 이렇습니다.newDb를 이전 데이터베이스(oldDb)와 비교합니다.해당 비교에서 변경 세트를 구하고 Red Gate를 사용하여 적용합니다.이 업그레이드 프로세스를 테스트로 구축할 수 있으며, 데이터베이스에 대한 작성 스크립트가 보관되는 한 곳이 있다는 것을 모든 개발자가 동의하도록 할 수 있습니다.여러 버전에 걸쳐 데이터베이스를 업그레이드하고 각 단계 간에 데이터 마이그레이션 스크립트 및 프로세스를 실행하는 경우(생성 및 데이터 마이그레이션 스크립트를 매핑하기 위해 XML 문서를 사용) 이와 동일한 방식이 효과적입니다.

편집: Red Gate 기법을 사용하면 Red Gate에서 업그레이드 스크립트를 제공하므로 업그레이드 스크립트가 아닌 작성 스크립트에만 관심이 있습니다.또한 인덱스, 저장 프로시저, 함수 등을 삭제하고 생성할 수 있습니다.

여기로 이동:

https://blog.codinghorror.com/get-your-database-under-version-control/

odetocode.com 웹사이트 링크 5개 목록으로 스크롤을 조금 내립니다.환상적인 5부작 시리즈.아이디어를 얻고 귀사의 팀에 적합한 프로세스를 찾는 출발점으로 삼겠습니다.

MSBuild나 NAnt와 같은 빌드 도구를 사용하는 것을 고려해야 합니다.크루즈 컨트롤의 조합을 사용합니다.SQL 객체를 비롯한 구현을 처리하는 NET, NANT 및 SourceGear Fortress.NAnt db 빌드 작업에서 sqlcmd를 호출합니다.포트리스로 체크인 된 후 개발자 및 스테이징 환경에서 스크립트를 업데이트 할 수 있습니다.

우리는 Visual Studio for Database Professionals 및 TFS를 사용하여 데이터베이스 배포를 버전화하고 관리합니다.이를 통해 데이터베이스를 코드(체크아웃, 체크인, 잠금, 버전 이력 보기, 분기, 빌드, 배포, 테스트 등)와 동일하게 취급할 수 있으며, 원하는 경우 동일한 솔루션 파일에 포함시킬 수도 있습니다.

개발자들은 로컬 데이터베이스에서 작업하여 공유 환경에서 서로의 변경 사항을 밟지 않도록 할 수 있습니다.TFS로 데이터베이스 변경 사항을 확인하면 통합 개발 환경에 구축, 테스트 및 배포할 수 있는 지속적인 통합이 가능합니다.릴리스 분기에는 별도의 빌드가 있어 후속 환경별로 차등 배포 스크립트를 생성합니다.

나중에 릴리스에서 버그가 발견되면 릴리스 브랜치로 가서 코드와 데이터베이스를 동시에 핫픽스할 수 있습니다.

이것은 훌륭한 제품이지만 마이크로소프트 마케팅 실수로 인해 초기에 채택이 지연되었습니다.원래는 Team System 하에서 별도의 제품이었습니다.따라서 개발자 에디션과 데이터베이스 에디션의 기능을 동시에 사용하려면 훨씬 더 비싼 Team Suite 에디션으로 업그레이드해야 했습니다.우리(그리고 다른 많은 고객들)는 이에 대해 Microsoft에 비통함을 주었고, 올해 DB Pro가 개발자 에디션으로 접혔으며, 개발자 에디션 라이센스를 가진 누구나 즉시 데이터베이스 에디션을 설치할 수 있다고 발표해 매우 기뻤습니다.

Gus는 DB Ghost(위의 DB Ghost)를 직접 언급했습니다. 가능성 있는 해결책으로 찬성합니다.

우리 회사가 DB Ghost를 어떻게 사용하고 있는지에 대한 간단한 개요:

• 초기 개발 중 새 DB에 대한 스키마가 합리적으로 정착된 후 DB Ghost 'Data and Schema Scripter'를 사용하여 모든 DB 객체(및 임의의 정적 데이터)에 대한 스크립트(.sql) 파일을 생성하고 이 스크립트 파일을 소스 제어(도구는 객체를 'Stored Procedures', 'Tables' 등의 폴더로 분리함)로 체크인합니다..).이때 DB Ghost 'Packager' 또는 'Packager Plus' 도구를 사용하여 독립 실행 파일을 생성하여 이러한 스크립트에서 새 DB를 생성할 수 있습니다.
• DB 스키마에 대한 모든 변경사항은 특정 스크립트 파일에 대한 체크인을 통해 소스로 체크인됩니다.
• 언제든지 패키지를 사용하여 (a) 새 DB를 만들거나 (b) 기존 DB를 업데이트하기 위한 실행 파일을 만들 수 있습니다.특정 경로 종속 변경(예: 데이터를 업데이트해야 하는 변경 사항)에 대해서는 사용자 지정이 필요하지만, 사전 업데이트 스크립트와 사후 업데이트 스크립트가 실행되고 있습니다.

'update' 프로세스는 깨끗한 'source' DB를 생성한 후(사용자 지정 스크립트 사전 업데이트 후), source DB와 target DB의 스키마를 비교하는 것입니다. DB Ghost는 대상 DB를 일치하도록 업데이트합니다.

우리는 프로덕션 DB를 정기적으로 변경하지만(7개의 다양한 프로덕션 환경에 14명의 고객이 있음), 필연적으로 DB Ghost 업데이트 실행 파일(빌드 프로세스 중에 생성됨)을 통해 충분히 많은 변경 사항을 배포합니다.소스에 체크인되지 않은(또는 릴리스 중인 해당 분기에 체크인되지 않은) 프로덕션 변경 사항은 LOST로 처리됩니다.이로 인해 모든 사용자가 변경 사항을 지속적으로 체크인해야 했습니다.

요약하자면:

• DB Ghost 업데이트 실행 파일을 사용하여 모든 DB 업데이트가 배포되도록 정책을 적용하는 경우, 중간에 수동으로 배포되었는지 여부에 관계없이 개발자가 변경 내용을 일관되게 체크인하도록 '강제'할 수 있습니다.
• DB Ghost 업데이트 실행 파일을 만들기 위해 빌드 프로세스에 단계(또는 단계)를 추가하면 DB가 스크립트에서 생성될 수 있는지(즉, DB Ghost가 업데이트 실행 파일 패키지를 생성할 때에도 '소스' DB를 생성하기 때문에), 그리고 업데이트 패키지를 실행하기 위한 단계(또는 단계)를 추가하면 [4가지 테스트 DB 중 하나에] 테스트가 사실상 수행됩니다.말씀하신 대로], 테스트 DB를 소스와 일치하도록 유지할 수 있습니다.

이 툴을 사용하여 '쉽게' 구현되는 변경 사항(실제 관련 툴 모음)에는 다음과 같은 몇 가지 주의 사항과 제한 사항이 있지만, 모두 (적어도 당사의 경우) 매우 경미합니다.

• 개체 이름 변경은 사용자 지정 스크립트 중 하나에서 수행해야 합니다.
• 전체 DB는 항상 업데이트되며(예: 단일 스키마의 개체는 단독으로 업데이트할 수 없음), 메인 애플리케이션 DB에서 고객별 개체를 지원하기가 어렵습니다.

Refactoring Databases라는 책은 개념적 수준에서 이러한 문제들을 많이 다루고 있습니다.

툴에 관한 한, 저는 DB Ghost가 SQL Server에 적합한 것으로 알고 있습니다.비주얼 스튜디오의 Data Dude 에디션이 최근에 정말 개선되었다고 들었는데 경험이 없습니다.

지속적인 통합 스타일의 데이터베이스 개발은 필요한 데이터베이스 복사본의 수 때문에 매우 빠르게 리소스를 집약합니다.데이터베이스가 개발자 워크스테이션에 들어갈 수 있는 경우에는 매우 가능하지만, 데이터베이스가 너무 커서 그리드 전체에 배포해야 하는 경우에는 실용적이지 않습니다.이를 위해서는 기본적으로 개발자당 데이터베이스 복사본 1개(procs 변경뿐만 아니라 DDL 변경을 수행하는 개발자) + 공통 복사본 6개가 필요합니다.일반 사본은 다음과 같습니다.

1. INT DEV --> 개발자는 통합 테스트를 위해 자신의 리팩토링을 INT DEV에 "체크인"합니다.통합 테스트가 통과되면 이 데이터베이스는 DEV로 복사됩니다.
2. DEV --> 데이터베이스의 "공식" 개발 복사본입니다.INT DEV는 DEV 복사본으로 정기적으로 새로 고침됩니다.새로운 리팩터링 작업을 하는 개발자들은 DEV로부터 데이터베이스의 새로운 복사본을 얻습니다.
3. INT QA --> QA팀을 제외하고 INT DEV와 동일한 아이디어입니다.여기서 통합 테스트를 통과하면 이 데이터베이스는 QA 및 DEV*로 복사됩니다.
4. QA
5. INT PROD --> 생산을 제외하고 INT QA와 동일한 아이디어입니다.여기서 통합 테스트를 통과하면 이 데이터베이스는 PROD, QA* 및 DEV*로 복사됩니다.
6. PROD

*DEV/QA/PROD 라인을 통해 데이터베이스를 복사할 때는 스크립트를 실행하여 특정 환경과 관련된 테스트 데이터를 업데이트해야 합니다(예: QA 팀이 테스트하는 데 사용하지만 프로덕션에 존재하지 않는 QA 내 사용자 설정).

한 가지 가능한 해결책은 테스트 데이터베이스에 DML 감사를 구현한 다음, 최종 테스트 및 실시간 배포를 위해 감사 로그를 스크립트로 롤링하는 방법입니다.SQL Server 2008은 DML 감사 기능을 크게 향상시켰지만 SQL Server 2005조차도 트리거를 통해 DML 감사 기능을 지원합니다.

이 게시물에는 제가 팔로우하고 싶은 링크가 많이 있습니다(몇 년 전에 시스템을 "롤링"했는데, 유사점이 있는지 확인해야 합니다).여러분이 필요로 하는 한 가지, 그리고 제가 이 링크에 언급되기를 바라는 것은 규율입니다.저는 누군가가 언제든지 어떤 것을 바꿀 수 있다면 어떤 자동화된 시스템이 어떻게 작동할 수 있는지 잘 모르겠습니다.(당신의 질문은 이러한 일이 생산 시스템에서 일어날 수 있다는 것을 암시하지만, 분명히 사실일 수는 없습니다.)

데이터베이스, 특히 프로덕션 데이터베이스에 대한 변경사항을 관리하는 업무를 전담하는 한 사람(가명 "데이터베이스 관리자")을 두는 것은 매우 일반적인 해결책입니다.X 개발 및 테스트 데이터베이스 전반에 걸쳐 일관성을 유지하는 것과 관련하여: 많은 사용자가 해당 데이터베이스를 사용하고 있다면, 다시 한 번 개인이 변경 사항에 대한 "해결 센터" 역할을 수행하도록 함으로써 최상의 서비스를 제공받을 수 있습니다. 모든 사용자가 자신의 데이터베이스 인스턴스를 가지고 있다면, 해당 데이터베이스를 정상적으로 유지할 책임이 있습니다.또한 중앙의 일관된 데이터베이스 "소스"를 보유하는 것은 기본 데이터베이스를 새로 고쳐야 할 때 매우 중요합니다.

다음은 관심 있는 Stack Oflow 최신 게시물입니다. 사용하지 않고 sql-server의 테스트-인스턴스-production-data-without-refresh 방법입니다.

Red Gate에는 빌드 자동화를 달성하는 방법을 설명하는 문서가 있습니다. http://downloads.red-gate.com/HelpPDF/ContinuousIntegrationForDatabasesUsingRedGateSQLTools.pdf

이는 SSMS 및 기존 소스 제어 시스템과 통합되는 SQL Source Control을 중심으로 구축됩니다.

A를 써놨습니다.자동화된 방식으로 데이터베이스 버전 관리를 처리하는 NET 기반 도구.NAT은 여러 환경에 대한 데이터베이스 업데이트(패치 포함)를 처리하고, 스크립트가 실행된 각 데이터베이스에 로그를 보관하며, 이 모든 작업을 자동화된 방식으로 수행하기 위해 프로덕션에서 이 도구를 사용해 왔습니다.명령줄 콘솔이 있으므로 이 도구를 사용하는 배치 스크립트를 만들 수 있습니다.확인해보세요: https://github.com/bmontgomery/DatabaseVersioning

가치가 있지만, 이것은 제 전 고용주가 사용한 간단하고 저비용 접근 방식의 실제 사례입니다. (그리고 저는 기본적인 첫 단계로서 현재 고용주에게 깊은 인상을 주려고 노력하고 있습니다.

'DB_VERSION' 또는 유사한 테이블을 추가합니다.모든 업그레이드 스크립트에서 해당 테이블에 업그레이드를 설명하는 데 적합한 열의 개수 또는 개수만큼 포함할 수 있는 행을 추가합니다. 하지만 최소한 {VERSION, EXECUATION_DATE, DESCLION, EXECUATION_USER }을(를) 제안합니다. 이제 진행 중인 상황에 대한 구체적인 기록이 나왔습니다.누군가가 자신의 권한 없는 스크립트를 실행하는 경우에도 위의 답변에 따라야 하지만, 이는 기존 버전 관리 기능(즉, 없음)을 획기적으로 개선하는 간단한 방법일 뿐입니다.

이제 데이터베이스의 v2.1에서 v2.2로 업그레이드 스크립트를 사용하여 단독 소유자가 실제로 데이터베이스에서 이 스크립트를 실행했는지 확인하려면 VERSION = 'v2.2'에서 행을 검색하고 결과가 나오면 이 업그레이드 스크립트를 실행하지 마십시오.필요한 경우 콘솔 유틸리티 앱에 내장할 수 있습니다.

언급URL : https://stackoverflow.com/questions/504909/database-deployment-strategies-sql-server