끊임없이 변화하는 데이터베이스 차원을 어떻게 처리합니까?

9

지난 2 개월 정도 동안 데이터베이스 내에서 릴리스 관리를 처리 할 솔루션이나 사례를 찾고있었습니다. 나는 사람들이 이것을 처리하는 가장 좋은 과정으로 보는 것을 찾고 있습니다.

데이터베이스를위한 3 가지 환경이 있습니다 :

개발
사용자 수락 테스트 (UAT)
생산

문제는 때때로 개발 데이터베이스 내에서 여러 가지 사항을 변경하고 배포 할 때가되었으며 일부 기능이 UAT에 릴리스 될 수없는 경우가 있습니다.

최근에 모든 엔티티를 저장하기 위해 Red Gate SQL Source 컨트롤을 사용하기 시작했습니다 (정기 커밋 포함).

나는 변경 세트를 기반으로 진행하려고 생각했습니다 (즉, 변경 세트 X 및 뒤의 모든 것이 이제 UAT로 푸시되고 있다고 말합니다). 특히 사람들은 잊어 버리기 때문에). 변경 집합 접근 방식을 사용하는 또 다른 문제는 수정해야 할 저장 프로 시저에 버그가있는 경우 변경 집합 수는 수정에 대한 최대 변경 집합 범위를 벗어나므로 수정해야하는 경우입니다. 최대 변경 세트에서 데이터베이스를 다시 작성하면 버그가 다시 발생합니다.

프로세스에 대한 제안?

감사

— 유다
소스

데이터베이스 스크립트가 "실제"코드와 동일한 소스 제어에없는 것 같습니다. 왜 이런거야? "소스 코드"로 취급하여 개별 브랜치에 넣을 수 있습니까?

— Mike M.

우리는 현재 소스 컨트롤에 스크립트의 개발 버전 만 저장하고 UAT / Production은 모두 활성 개발과 동기화되지 않습니다. 소스 제어의 각 스크립트는 개발자가 커밋을 수행 할 때마다 업데이트됩니다. 개별 지점의 문제는 모든 사람이 사용하는 하나의 중앙 집중식 데이터베이스가 있다는 것입니다 (더 큰 변경을 위해 별도의 데이터베이스를 분기 함).

1

릴리스에 대한 분기를 작성하고 릴리스와 관련된 변경 사항 만 커미트 할 수 있습니다. 다른 모든 변경 사항은 트렁크에서 수행해야합니다. 이를 위해서는 두 개의 개발 데이터베이스가 필요합니다. 이것이 문제입니까?

하나는 꽤 빨리 구식이 될 것 같습니다. 아니? 내 프로젝트 중 하나에 대해 데이터베이스의 대대적 인 정비가 진행 중이므로 수정되지 않은 버전의 데이터베이스에서 여전히 활발한 개발이 이루어질 수 있도록 그 중 하나를 분기했습니다. 그러나 매일 나는 분기 버전이 점점 더 오래되어 점점 그것이 최신인지 확실하지 않습니다 ... 나는 전에 이와 같은 상황을 실제로 다룰 필요가 없었습니다.

— judda

5

마이그레이션

리포지토리에 있고 앱과 함께 태그가 지정된 위아래.

스키마를 수정하고 스키마 버전을 업데이트하는 SQL 플랫 파일을 사용하여 DIY를 수행 할 수도 있습니다. 당신이 정말로해야 할 일은 :

마이그레이션을 소스 코드 옆에 두십시오. 버전과 태그가 함께 있어야합니다.
모든 환경에서 항상 관리되는 변경 (마이그레이션) 사용
어떤 환경에서도 임시 수정을 허용하지 않습니다

개발자는 개발 변경을 수행 할 수 있지만 변경 사항을 캡처 한 후에는 항상 DB를 날려 버리고 마이그레이션으로 다시 빌드해야합니다.

— 다이어트
소스

스크립트에서 버그가 발견되면 어떻게됩니까? SQL 스크립트로 돌아가서 업데이트합니까?

— judda

1

아니요, 새 마이그레이션을 작성합니다 (스키마 버전이 증가 함). 데이터베이스에서 스키마 버전을 확인하여 수정 사항이 배치되었음을 알 수 있습니다.

— dietbuddha

도와 주셔서 감사합니다. 언뜻보기에 이것은 매우 견고한 접근 방식이며 분기 전략과 유사합니다.

— judda

2

소스 컨트롤!

svn / git / p4를 거치지 않고 개발 바이너리를 프로덕션 환경에 직접 배포하지 않는 이유는 무엇입니까? 개발자가 로컬 변경 사항을 테스트 할 수 있도록 프라이빗 인스턴스를 가져 오지만 개발 데이터베이스로 이동해야 할 경우 체크인 된 ddl 파일을 통해 이동해야합니다. 이러한 ddl 변경 사항을 자동으로 적용하는 도구를 작성할 수도 있습니다 (기존의 올바른 방법은 모르겠습니다).

DB 스키마 변경에 대한 제한이 있고 (더 이상 sqlplus-> ddl을 발행하지 마십시오!) 엄격한 계정 제어 (모든 사람이 ddl에 액세스 할 수 없음)를 가지면보다 관리하기 쉬워집니다.

— 수부 산 카라 수 브라마 니안
소스

1

안타깝게도 데이터베이스가 너무 커서 개인 세션을 실행하기에는 개발자간에 전달할 수 없습니다. 또한 지금은 팀 기반 개발에 더 의존하지 않는 것 같습니다. 현재 두 팀을 연결하는 UI 작업을 위해 사람들과 이야기하면서 백엔드 개발을 수행하기 때문입니다. 모든 변경 사항을 확인한 다음 데이터베이스에서 최신 정보를 얻는 것이 매우 번거로운 것 같습니다.

— judda

개발 데이터베이스가 프로덕션 데이터베이스와 동일한 크기 여야하는 이유는 무엇입니까? 그것들은 동일한 스키마를 가질 수 있으며 모든 데이터를 가진 특별한로드 테스트 집합을 가질 수도 있지만 로컬 dev 데이터베이스는 작을 수 있습니다. 이것은 또한 데이터 유출 문제 등을 방지합니다. 이론적으로 prod 데이터는 전혀 개발에 영향을 미치지 않아야합니다.

— Subu Sankara Subramanian

모든 데이터는 클라이언트에서 제공 한 파일을 처리 한 다음 필요한 데이터로 변환하는 데이터로드 프로세스를 통해로드됩니다. 따라서 개발 과정에서 모든 데이터로드를 확인해야하는 경우 개발 데이터와 제품 데이터를 분리 할 수 없습니다. 그러나 크기가 같을 필요는 없지만 의미있는 정보를 생성하기 위해 만든 보고서를 작성하기 위해서는 비슷한 양의 데이터가 필요합니다.

— judda

전체 DB를 복제 할 필요는 없습니다. Oracle에서는 모든 사용자에게 고유 한 스키마가 있으며 하나의 응용 프로그램 스키마가 있습니다. 응용 프로그램 스키마의 모든 개체에 대한 공용 동의어를 만듭니다. 그런 다음 모든 사용자는 자신의 스키마에서 개체 (테이블, SP)를 변경할 수 있으며, 연결되어 있으면 개체 이름이 사용됩니다. 스키마에없는 객체의 경우 동의어 woukd가 사용됩니다. 이것이 우리가 일하는 방식입니다.

— softveda

0

마이그레이션 사용에 대한 제안에 이어 Ruby on Rails 및 Entity Framework 4.3과 같은 마이그레이션을 지원하는 O / RM을 사용할 수 있습니다. 변경 세트와 관련하여 적용 할 마이그레이션을 (일반적으로) 선택할 수 없습니다.

또 다른 실행 가능한 옵션 (Microsoft 스택을 사용하는 경우 플랫폼을 언급하지 않은 경우)은 Visual Studio 데이터베이스 도구를 사용하여 SQL을 관리하는 것입니다. 리팩토링 (컬럼 이름 바꾸기 / 제거 등)이 내장되어 있으며 모델을 검증합니다. 예를 들어, 저장된 프로 시저가 더 이상 존재하지 않는 열을 참조하면 알려줍니다.

— 마이클 브라운
소스