코드 분기간에 공유되는 데이터베이스 스키마를 처리하는 효율적인 방법은 무엇입니까?

각 지점이 결국 기본 지점으로 다시 병합되고 본질적으로 새로운 기능을 개발하기 위해 격리되는 여러 지점이있는 프로젝트에서 작업합니다.

MS SQL Server 인 데이터베이스에는 공유 스키마가 있지만 각 브랜치는 진행될 때 스키마를 변경합니다.

나의 주요 질문은 메인 브랜치에서 파생 브랜치로 스키마 공유를 처리하는 좋은 방법입니다. 분기?

버전 관리 및 데이터베이스 에서 정교한 다음 방법을 성공적으로 사용했습니다 .

• 메타 데이터로 버전 번호 유지 (데이터베이스 확장 속성 사용)
• 모든 스키마 변경은 현재 버전에서 다음 버전으로 업데이트되는 스크립트로 코딩됩니다.
• 응용 프로그램은 버전 0 (초기 배포)에서 현재 버전으로 업그레이드하는 모든 스크립트와 함께 제공됩니다.
• 모든 변경은 스크립트를 통해 수행됩니다. 사전 및 조회 테이블 항목과 같은 '시스템'데이터 변경 포함
• 배포시 응용 프로그램은 디스크상의 스키마 버전을 확인한 다음 모든 업그레이드 단계를 실행하여 스키마를 현재 필요한 버전으로 가져옵니다.

나는 종종 이것이 객체 정의 스크립트를 소스 제어하에 유지하는 것과 어떻게 다른가?에 대한 의견을 듣는다. 새로운 버전의 앱을 배포 할 때 단순히 새 데이터베이스를 만들지 않기 때문에 차이점이 큽니다. 대부분의 경우 앱은 기존 데이터를 포함하여 기존 데이터베이스를 업그레이드해야 합니다 . 이것은 업그레이드 과정에서 기존 데이터의 무결성과 일관성을 보장하기 위해 업그레이드 단계에서 필요한 중요한 차이점입니다. 일부 작업은 코드에서 사소한 일이지만 (테이블 개체 정의 스크립트에 기본값이 null이 아닌 열을 추가 함) 실제 배포에서 실제로는 매우 고통 스럽습니다 (테이블에 15 억 개의 행이 있고 추가 열이 부족함) '간단한'방법으로 수행 된 경우 로그 공간).

이것이 분기와 어떻게 작동합니까?

• 분기가 생성되면 현재 스키마 버전을 스냅합니다 (예 : 버전 1.6).
• 팀이 지점에서 작업을 시작하면 새 버전 1.7을 추가 한 다음 업그레이드 단계를 1.6에서 1.7로 코딩하기 시작합니다.
• 지점에서 수정이 완료되면 업그레이드 단계가 변경됩니다. 항상 v 1.6에서 1.7로 업그레이드되는 스크립트를 실행하지만 해당 스크립트의 기능은 분기의 정상적인 코드 반복 및 체크인에 따릅니다.
• 지점 개발 완료, 역 통합 준비 (기준으로 다시 병합)
  • 기준선에서 지점으로의 새로운 순방향 통합을 수행합니다. 통합으로 인해 스키마 버전이 변경되지 않으면 모든 것이 정상이면 분기가있는 그대로 통합을 되돌릴 수 있습니다. 버전 1.7이 새로운 기준 버전이됩니다.
  • 흥미로운 점은 그 동안 다른 브랜치가베이스로 역 통합되어 현재 기본 스키마 버전이 1.7로 변경된 경우입니다. 이 경우 지점은 배포 대상 스키마 버전을 1.8로 높이고 이전의 1.6에서 1.7로 업그레이드 단계를 검토하여 새 환경에서 어떻게 작동하는지 확인하여 1.7에서 1.8로 업그레이드해야합니다. 논리적 스키마 충돌을 해결하고 스크립트를 변경해야 할 수 있으며 테스트를 수행해야합니다. 완료되면 지점은베이스로 역 통합 될 수 있습니다. 제품의 배포 된 대상 버전이 이제 1.8이됩니다.
  • 스키마 버전 1.6에서 분기 된 다른 분기가 역 통합하려는 경우 스키마 버전을 1.9로 높이고 업그레이드 스크립트를 1.8에서 1.9로 테스트 한 후 다시 기본으로 통합 할 수 있어야합니다.

도구, 마법 스키마 diff 스크립팅, 마법사 및 마우스 오른쪽 단추 클릭 생성 스크립트가 없습니다. 소스 (스크립트)를 기반으로하는 100 % 개발자 주도 프로세스입니다. 많은 사람들이이 전체 과정이 정교하다고 생각하지만 효과가 있습니다. 실제로 SQL Server 사용자는 SQL Server를 일상적으로 사용할 때이 프로세스의 결과를 이미 활용했습니다. SQL Server 자체는 매우 유사한 데이터베이스 업그레이드 프로세스를 사용하며 예상대로 제품 개발 프로세스는 광범위하게 사용됩니다. 분기의 문제와 언급 한 문제는 해결해야 할 매우 실제적인 문제입니다.

BTW, 분기 / 통합이 실제로 발생하는 방식은 소스 제어 제품마다 다르므로 perforce 통합 작동 모드에 익숙한 용어를 사용하고 있습니다.

내 대답은 Remus 's만큼 길지 않을 수도 있지만 이것이 정말 좋은 해결책이라는 것을 알았습니다. 아직 프로덕션 환경에 설치하지 않았으므로 YMMV *.

리퀴베이스

기본적으로 XML 파일은 XML 파일 내부에서 새 요소로 데이터베이스의 스키마를 변경하는 XML 파일입니다. 예를 들면 다음과 같습니다.

<createTable tableName="department">
            <column name="id" type="int">
                <constraints primaryKey="true" nullable="false"/>
            </column>

그것은 완전히 다듬어 진 구문을 가지고 있으므로 데이터베이스에 원하는 것을 거의 할 수 있습니다.

또한 Liquibase 설치에서 버전 관리 할 데이터베이스를 지정합니다. 그런 다음 포함 된 Java 실행 파일 (jar 파일)로 .xml을 "실행"합니다. 이것은 본질적으로 XML에 지정된 변경 사항을 데이터베이스에 다시 작성합니다.

중요한 것은이 XML 파일을 코드와 동일한 버전의 폴더에 저장한다는 것입니다. 제 경우에는 Git이었습니다. 내 프로젝트 폴더 (/.git와 같은 수준) 에이 XML 파일이 있고 브랜치를 전환 할 때마다 XML 파일이 해당 브랜치 버전으로 변경되고 .jar 파일을 실행하면 데이터베이스가 해당 브랜치를 반영합니다.

* 참고 : Java를 SQL Server에 연결하는 데 문제가있어서 구현을 완료하지 못했습니다. 일부 jdbc 드라이버가 필요하며 기분이 좋지 않았습니다. 따라서 마일리지가 다를 수 있습니다.

Red Gate에서는 곧 SQL Compare 및 SQL Source Control을 모두 활용하는 데이터베이스 버전 관리 솔루션을 출시 할 예정입니다. 마이그레이션 스크립트 업그레이드 방법을 사용하고 소스 제어 개정판에 해당하는 버전 확장 특성으로 데이터베이스를 스탬핑합니다.

12 월 중순에 출시 될 예정입니다. 현재 출시 후보가 있습니다. 자세한 내용을 보려면 다음 사이트를 방문하십시오 :

http://www.red-gate.com/products/sql-development/sql-source-control/entrypage/migration

앞으로 몇 달 안에이 솔루션을 구축하기를 기대하고 있으므로 의견을 보내 주시기 바랍니다.

스크립트를 생성하고 해당 스크립트를 소스 제어하에 유지하여 스키마 변경을 처리하는 경우 다른 코드 병합과 같이 변경 사항을 처리 할 수 ​​있습니다. 자동 병합 또는 더 많은 수동 개입을 선택하도록 선택할 수 있습니다.

라이브 웹 사이트와 데이터베이스 스키마를 변경 해야하는 여러 개발 지점에서 작업하는 비슷한 상황에 처해 있습니다.

git과 함께 잘 사용할 수있는 post-checkout과 post-merge hook을 작성하여 해결했습니다. 모든 마이그레이션을 SQL 파일 형태로 별도의 디렉토리에 저장하고 변경된 PHP 코드와 함께 커밋합니다. 내가 수행 할 때마다

git checkout

또는

git merge

git은 자동으로 적절한 상향 및 하향 이주를 호출합니다. Github 구현을 참조하십시오 .