프로덕션에서 지속적으로 제공되는 관계형 데이터베이스 (및 스키마) 마이그레이션 패턴은 무엇입니까?연속 데이터 전송에서의 프로덕션 데이터 마이그레이션 패턴
많은 전통적인 개발에서 DBA는 현재 릴리스주기에 생성 된 많은 작은 스크립트 중에서 큰 마이그레이션 스크립트를 정렬합니다. 그러나 CD에서 개발자는 변경 사항을 프로덕션으로 보내고 다른 스크립트로 컴파일 할 때까지 기다릴 필요가 없습니다.
필자는 레일스 마이그레이션에 대해 알고 있지만 원시 SQL 스크립트를 사용하는 것이 더 합리적입니다.
나는 또한 flyway과 같은 도구를 사용하여 마이그레이션을 관리했지만 프로덕션 환경에서 많은 사람들을 사용하지 않았습니다. 이것이 제가 여기있는 일반적인 관행이 궁금한 이유입니다.
플라이 웨이는 지속적인 배송/배치에 적합합니다. 많은 클라이언트가 프로덕션을 포함한 모든 환경에서이를 사용합니다. 1
이전 응용 프로그램 코드가 기존 DB와 함께 작동
단계 :
환경에서 DB 마이그레이션을 계단식에 대한 가장 중요한 것은 3 단계 과정을하는 것입니다.
2 단계
새로운 응용 프로그램 코드 배포 및 시작시 DB 마이그레이션 얻을. 이전 응용 프로그램 코드가 새 DB와 계속 작동하도록이 마이그레이션은 역 호환 가능해야합니다. 이것은 필수적인 이유는
이 단계에는 작업을 수행하기위한 호환성보기 및 트리거가 포함될 수 있습니다.
변경이 작업을 검증 한 후 3 단계
, 응용 프로그램 코드의 다음 버전은 남아있는 오래된 호환성 (1 단계) (폐기하는 데 필요한 DB 마이그레이션과 함께 배치 를 가져옵니다 단계 2) 구조로부터.
변경 사항을 단일 (원시) sql 파일로 구현 한 다음 sqlpatch을 사용하여 마이그레이션 스크립트를 작성하십시오.
나는 보통 데이타베이스를위한 단일 저장소와 CD 환경이 첨부되어있다. 대개 프로덕션 및 개발 데이터베이스가 있으며 해당 브랜치로 이동할 때 자동으로 마이그레이션됩니다.
이 설정을 사용하면 기능 분기에 대해 다른 데이터베이스를 설정하고 실험 할 수 있습니다. Sqlpatch는 별도의 SQL 파일에있는 모든 종속성을 처리하므로 다른 분기에서 기능 분기를 쉽게 병합 할 수 있습니다.
BTW, 나는 sqlpatch의 작성자입니다. – Elmer
나는 이것이 오래된 게시물이라는 것을 알고 있지만 이것이 어떻게 포장되어야하는지에 대한 아이디어가 있다면 궁금해.두 번째 패키지는 다음과 같습니다. 1 : 새 db (이전 버전)와 함께 작동하도록 프로비저닝 된 새 코드 2 : Db 마이그레이션 3 : 새 코드, 더 이상 지원되지 않는 고정식 코드 db 종종 이러한 모든 변경이 수행되고 소스 제어에 커밋되어 빌드가 트리거됩니다. 적절한 패키지로 분할하여 배포 파이프 라인에 보낼 수있는 도구에 대해 알고 있습니까? –
"새 응용 프로그램 코드가 배포되고 시작시 DB를 마이그레이션합니다." 제 생각에 마이그레이션 스크립트가 배포 스크립트의 일부로 실행되는 것이 합당한 것처럼 보입니다. 그 일에 어려움이 있습니까? –