프로덕션 데이터베이스의 스키마 변경 내용을 마이그레이션 관리 프로세스에 병합하려면 어떻게합니까?

Question

우리 팀은 데이터베이스 마이그레이션 관리를 위해 dbdeploy를 평가하고 있습니다. 마이그레이션을 사용하려면 마이그레이션을 모든 변경에 대해 작성하고 프로덕션에 도달하기 위해 로컬에서 개발로 테스트 단계까지 승격해야한다는 프로세스 규율이 필요합니다.

때때로 우리 프로덕션 DBA 팀이 프로덕션 환경에 직접 스키마를 변경합니다. 현재 개발중인 데이터베이스 버전과의 변경을 위해 새 마이그레이션을 작성하면 해당 마이그레이션이 프로덕션 환경에 배포 될 때까지 이미 변경 사항이 포함 된 스키마에 대해 해당 마이그레이션이 테스트되지 않습니다. 이것은 나를 염려합니다.

다른 옵션은 기본 스키마로 직접 변경 한 다음 모든 환경 (로컬, 개발, 테스트, 스테이지)에서 데이터베이스를 다시 작성하는 것입니다. 새로운 스키마로 인해 하나 이상의 마이그레이션이 중단 될 수 있기 때문에이 접근 방식은 저를 염려합니다.

현재이 시나리오를 처리하는 사람들은 누구입니까?

Answer 1

프로덕션 스키마의 DB 변경은 수시로 발생해야합니다. 이것들은 문서화되어야하고 개발 팀에 최대한 빨리 전달되어야하지만 매우 중요합니다. 영향을받은 유스 케이스/기능 및 가능한 버그 추적 문제에 대한 주석과 함께 실행되는 일반 텍스트

라이브 DB를 개발자가 개발할 때마다 다시 가져 와서 개발자가 가지고있는 것과 비교하는 것 (스키마 임) 뿐만 아니라 좋은 생각입니다.

Answer 2

DBA가 프로덕션 DB에서 변경할 수있는 유일한 점은 성능 향상을 위해 여기 저기에 인덱스를 추가하고 몇 가지 sprocs를 조정하는 것입니다. DB에 대한 다른 모든 변경 사항은 일반적으로 DB 스키마를 응용 프로그램과 호환되지 않게 렌더링 할 수 있습니다.

이 점을 염두에두고 실제로 버전을 지정해야하는 것은 sprocs이며 소스 제어를 확인하는 것은 DBA의 책임입니다. 인덱스는 훨씬 더 휘발성이 높기 때문에 실제로 마이그레이션 스크립트에 포함되지 않을 수 있습니다.

Answer 3

우리는 프로덕션 DB의 복사본을 테스트 서버에 밤새 복원합니다.

이는 역할을 : 우리는

우리는 실제 데이터에 대해 테스트 할 수 있습니다 변경 한 내용을 재설정 할 수 있습니다

참조 사본 (코드 및 데이터)으로

• 우리는 편 수 새로운/오래된 코드 preformance에 의해
• 우리는 100 % 안전한 변경/롤백 스크립트 (레드 게이트)를 생성 할 수 있습니다. (Red Gate)

우리는 dev/test 데이터베이스 등을 재구성하지 않지만 우리의 동료 프로젝트 중 일부는 않습니다. 그러나 데이터베이스가 스키마와 코드가 아니기 때문에 이점에 대해서는 확신 할 수 없습니다. 데이터이기도합니다. 이것은 순응 한 .net 앱과 다릅니다.

내 가게에서는 승인없이 DB를 변경 (변경 사항이 전혀 발생하지 않음)했습니다. 그리고 그것은 일어났습니다.