진화 데이터베이스 마이그레이션 및 기본 데이터

Question

우리는 릴리스 사이클이 끝날 때 릴리스에 대한 모든 업그레이드 스크립트를 생성해야하는 번거 로움을 없애기 위해 응용 프로그램의 데이터베이스 업그레이드 프로세스를 다시 평가하고 있습니다. 우리는 migratordotnet과 같은 도구를 사용하여 기능과 함께 체크인되는 마이그레이션을 사용하여보다 진화적인 프로세스로 전환하려고합니다. 이는 스키마 변경을 관리하는 매우 정교한 방법처럼 보입니다.

그러나 Google 데이터베이스와 함께 제공되는 기본 데이터는 상당히 정기적으로 변경 될 수 있으며 이러한 데이터 업데이트 중 일부는 마이그레이션 프로세스에 적합하지 않습니다. 예를 들어 Identity 기본 키가있는 테이블의 삽입은 쉽게 식별 할 수 없으므로 다운 그레이드 할 때 되돌릴 수 없습니다.

사람들이 기본 데이터를 어떻게 관리하는지 궁금합니다. 그들은 스킴 이전 프로세스 외에도 그것을 관리 했습니까? 또는 마이그레이션 중에 삽입이 수행되지만 다운 그레이드 중에 데이터 제거가 수행되지 않습니까?

Answer 1

우리에게있어 DB 마이그레이션은 일상적인 개발 프로세스의 일부입니다. 개발자는 필요한 변경을 수행하는 프로그램이나 스크립트를 커밋해야합니다. 이는 관련 기능이 구현되는 즉시 발생하며 "릴리스 사이클의 끝에서"발생하지 않습니다.

다운 그레이드는 거의 문제가되지 않지만 버전 정보가있는 열을 만듭니다. 업그레이드가 성공하고 고객이 새 버전을 유지하기로 결정하면 열을 다시 놓으십시오 (또는 그대로 두십시오).

성공의 열쇠는 모든 데이터를 포함하여 데이터베이스를 처음부터 새로 만들거나 (H2와 같은 인 메모리 DB 또는 각 개발자 컴퓨터에 설치된 DB를 사용하여) 광범위하게 테스트 케이스를 작성한 다음 모든 데이터를 마이그레이션하는 것입니다 방법을 통해. 익명화 된 데이터를 프로덕션 서버에서 테스트 케이스로 가져와 버그를 추적하고 고객의 개인 정보를 침해하지 않고 테스트를 개선하거나 개발자의 길을 탈 수도 있습니다.