DB 변경 사항을 개발에서 QA로, 프로덕션 환경으로 마이그레이션하는 좋은 방법은 무엇입니까? 현재 우리는 :

1. SQL 파일에서 변경 사항을 스크립트하고이를 TFS 작업 항목에 첨부하십시오.
2. 작품은 동료 검토
3. 작업을 테스트 할 준비가되면 SQL은 QA에서 실행됩니다.
4. 작업은 QA 테스트
5. 작업 준비가 완료되면 프로덕션 데이터베이스에서 SQL이 실행됩니다.

이 문제는 매우 수동적이라는 것입니다. 개발자가 잊어 버린 경우 SQL 또는 동료 검토자를 첨부하는 것을 기억하는 개발자에게 의존합니다. 때로는 문제를 발견 한 테스터 또는 QA 배포자가 될 수도 있습니다.

두 번째 문제점은 두 개의 개별 태스크가 동일한 데이터베이스 오브젝트를 변경하는 경우 변경 사항을 수동으로 조정해야하는 경우가 있습니다. 이것은 현재의 방식 일 수도 있지만 여전히 이러한 문제 나 무언가를 "비틀 거리는"자동화 된 방법이 있어야합니다.

우리의 설정 : 우리의 개발 상점은 많은 DB 경험을 가진 개발자들로 가득합니다. 우리의 프로젝트는 매우 DB 지향적입니다. 우리는 주로 .NET 및 MS SQL 상점입니다. 현재 우리는 작업을 추적하기 위해 MS TFS 작업 항목을 사용하고 있습니다. 이는 변경 세트를 작업 항목에 연결하므로 QA 및 프로덕션 환경으로 마이그레이션 할 때 포함해야하는 변경 사항을 정확하게 찾을 수 있기 때문에 코드 변경에 편리합니다. 현재 DB 프로젝트를 사용하고 있지 않지만 향후 프로젝트로 전환 할 수 있습니다 (아마도 답변의 일부일 수 있음).

나는 나를 위해 이와 같은 것들을 돌보는 소스 제어 시스템에 매우 익숙하며 SQL에 대해서도 같은 것을 원합니다.

VS 환경에서는 항상 데이터베이스 프로젝트를 사용하여 업데이트 스크립트를 구현했습니다. 내 스크립트에는 "DatabaseUpdate17.sql"또는 "PriceUpdateFebruary2010.sql"과 같은 상상할 수없는 이름을 사용하는 경향이 있습니다. 그것들을 데이터베이스 프로젝트로 사용하면 팀 서버 작업, 버그 (그리고 코드 검토를 한 경우에도 버그)에 연결할 수 있습니다. 또한 각 데이터베이스 (권한이있는)에 스키마 변경 사항 수집을위한 테이블을 포함시킵니다.

CREATE TABLE [dbo].[AuditDDL](
    [EventID] [int] IDENTITY(1,1) PRIMARY KEY NOT NULL,
    [EventData] [xml] NULL,                    -- what did they do
    [EventUser] varchar(100) NOT NULL,         -- who did it
    [EventTime] [datetime] DEFAULT (getdate()) -- when did they do it
    )
GO

음, 그것은 6 Ws 중 3 개를 처리합니다 .

CREATE TRIGGER [trgAuditDDL]
ON DATABASE 
FOR DDL_DATABASE_LEVEL_EVENTS 
AS
INSERT INTO AuditDDL(EventData, EventUser)
SELECT EVENTDATA(), original_login()
GO

패치의 시작과 패치의 끝을 기록하는 insert 문을 포함합니다. 패치 외부에서 발생하는 이벤트는 살펴볼 것입니다.

예를 들어 "patch 17"에 대한 "begin patch"삽입은 다음과 같습니다.

INSERT INTO [dbo].[AuditDDL]
           ([EventData]
           ,[EventUser])
     VALUES
           ('<EVENT_INSTANCE><EventType>BEGIN PATCH 17</EventType></EVENT_INSTANCE>'
           ,ORIGINAL_LOGIN())
GO

인덱스가 재 구축 될 때도 포착되므로 해당 이벤트를 지우려면 매월 다음을 실행해야합니다.

DELETE FROM AuditDDL
WHERE [EventData].exist('/EVENT_INSTANCE/EventType/text()[fn:contains(.,"ALTER_INDEX")]') =1
GO

DELETE FROM AuditDDL
WHERE [EventData].exist('/EVENT_INSTANCE/EventType/text()[fn:contains(.,"UPDATE_STATISTICS")]') =1
GO

이전 버전은 서버 결함에 게시되었습니다 .

SOX 및 PCI-DSS 호환 환경에서는 프로덕션 서버에 액세스 할 수 없습니다. 따라서 스크립트는 미리 명확하고 연습해야합니다. 업데이트 스크립트 맨 위에있는 주석에는 새 테이블, 저장된 proc, 함수 등의 목록과 수정 된 테이블, 저장된 proc, 함수 등이 포함됩니다. 데이터가 수정되면 수정중인 대상과 이유를 설명하십시오.

두 번째 문제점은 두 개의 개별 태스크가 동일한 데이터베이스 오브젝트를 변경하는 경우 변경 사항을 수동으로 조정해야하는 경우가 있습니다. 이것은 현재의 방식 일 수도 있지만 여전히 이러한 문제 나 무언가를 "비틀 거리는"자동화 된 방법이 있어야합니다.

나는 우리가 이것을 자동으로 추적 할 수있는 도구를 본 적이 없습니다. 이전 고용주는 "데이터베이스 소유자"라는 원칙을 사용했습니다. 데이터베이스를 개인적으로 담당하는 사람은 단 한 명입니다. 이 사람은 해당 데이터베이스에 대해 작업하는 유일한 개발자는 아니지만 모든 변경 작업을 수행해야합니다. 이것은 변경 사항이 서로 충돌하고 손상되지 않도록 합리적으로 잘 작동했습니다.

SQL 소스 컨트롤을 보셨습니까? 이를 사용하여 SQL Server를 TFS / SVN / Vault 또는 VSS에 연결할 수 있습니다-http: //www.red-gate.com/products/sql-development/sql-source-control/

또 다른 솔루션은 PowerDesigner, ERWin 등을 사용하여 데이터베이스 변경 사항을 설계하고 관리하는 것입니다.

PowerDesigner에서 데이터베이스가 모델링되는 정책으로 전환하기 시작했습니다. 데이터베이스 구조 / 코드에 대한 모든 변경은 모델에서 수행되고 소스 제어로 체크인 된 다음 데이터베이스에서 변경을 구현하기 위해 모델에서 변경 스크립트가 생성됩니다. 이러한 변경 스크립트는 소스 제어에도 체크인됩니다. 많은 변경 사항을 동료 검토하고 PowerDesigner는 기본 제공 기능을 사용하여이를 매우 쉽게 만듭니다.

PowerDesigner는 단순한 데이터베이스 이상을 지원하는 일반 모델링 도구이므로이를 사용하여 요구 사항을 관리하고 개념적, 물리적 및 아키텍처 다이어그램 (OOM도)을 만드는 등의 작업을 시작합니다. 기본적으로 우리는이를 사용하여 백본을 제공합니다 소프트웨어 엔지니어링 프로세스.

(나는 PowerDesigner를 개발 한 Sybase와 아무런 관련이 없습니다. 그냥 저 안에 넣을 것이라고 생각했습니다).

DB 고스트

DB Ghost 는 데이터베이스 관리에 가장 좋아하는 도구입니다.

은혜

1. 데이터베이스의 모든 개체는 소스 제어에서 스크립트로 저장됩니다.
2. '정적 데이터'(조회 테이블 데이터)도 스크립팅 할 수 있습니다.
3. 소스 제어를 수동으로 업데이트하거나 '모델'개발 데이터베이스를 스크립팅하여 업데이트 할 수 있습니다.
4. 소스 제어 (정적 데이터 포함)의 스크립트에서 데이터베이스를 신속하게 빌드 할 수 있습니다 .
5. 프로덕션 인스턴스를 포함하여 데이터베이스 인스턴스 에 변경 사항을 배치 할 수 있습니다 .
   • 스크립트에서 작성된 '빌드 데이터베이스'를 기존 데이터베이스와 비교하고 변경 스크립트를 생성 할 수 있습니다.
   • 빌드 데이터베이스와 프로덕션 데이터베이스와 같은 데이터베이스의 두 인스턴스간에 변경 사항을 자동으로 동기화하도록 DB Ghost에 지시 할 수 있습니다.

[4]는 특히 로컬 변경이나 다른 환경에 대한 별도의 인스턴스 생성에 유용합니다. 실제로 데이터베이스에 영향을 미치는 모든 기능이나 버그에 대해 별도의 데이터베이스를 만드는 것이 매우 쉽습니다.

세부

명시 적 변경 또는 마이그레이션 스크립트를 유지 관리하는 것보다이 도구를 사용하면 얻을 수있는 가장 큰 장점은 명시 적 변경 또는 마이그레이션 스크립트 를 유지할 필요 가 없다는 것입니다. 대부분 데이터베이스의 '현재 버전'만 유지할 수 있습니다. 마이그레이션 스크립트 관리의 성가신 측면 중 하나는 테이블에있는 열 목록 (마이그레이션 스크립트 기반)을 쉽게 볼 수있는 방법이 없다는 것입니다. 물론 일부 변경은 명시 적 마이그레이션으로 수행해야하지만 별도의 스크립트로 처리하기에 충분히 쉽습니다.

데이터베이스를 스크립트 세트로 관리하고 새로운 인스턴스를 빠르게 생성 할 수 있다는 결과는 특히 중요한 데이터베이스 코드를 테스트하는 것이 매우 쉽고 재미 있다는 것입니다. 단위 테스트 에는 tSQLt 를 사용 합니다.

다른 DBMS와 비슷한 도구가 있기를 바랍니다.

나는 그것이 대부분의 DBA에게 과잉이라고 들린다.

데이터베이스 변경 사항 (및 DB 변경 사항 만)을 추적하기 위해 Ruby on Rails 사용을 고려 했습니까? 앱을 실행하거나 루비 코드 등을 작성할 필요는 없습니다. 그러나 마이그레이션 스타일 (그것이 호출 방식)이 매우 유용하다는 것을 알았습니다. http://guides.rubyonrails.org/migrations.html

SQL Server도 지원되므로 JRuby + JDBC를 사용해야 할 수도 있습니다.