FlyWay 마이그레이션 전략

Question

현재 우리는 FlyWay를 사용하고 있으며 dev : 개발자 용 로컬, QA 녀석을위한 응용 프로그램의 여러 인스턴스, 준비 ...와 같은 여러 환경을 가지고 있습니다. : 진행 중 -> 코드 검토 -> 품질 보증 -> 병합.

우리는 문제에 직면 : 지점 작업을하는 동안, 개발자를 가정 새로운 마이그레이션 버전을 제공, V331는 한편 품질 보증 사람이 다른 분기에 품질 보증을하고, B을 말할 수 말할 수 있습니다, QA 환경. 여러 개발자가 서로 다른 시간에 다른 브랜치에 동일한 버전 번호를 생성 할 수 있기 때문에 qa 환경에 이미 버전 v331이있을 수 있습니다 ... 분기 간 전환이 자주 발생하므로 qa 데이터베이스가 지저분 해지는 이유, 특히 테이블 schema_version이며, 이전 버전의 스키마를 수동으로 제거하고 마이그레이션 된 이전 버전의 문제를 해결 한 다음 환경에서 마이그레이션 프로세스를 다시 시작하도록 안내합니다. 여러 환경과 이동 경로를 어떻게 처리합니까? 모범 사례가 있습니까?

Answer 1

방법이 있습니다. 필요에 맞는지 확실하지 않습니다.

당신은 outOfOrder 구성 필드, 버전의 증분 값을 무시하고 이동 경로를 구성 할 수 있습니다 : 당신은 문제 번호와 버전을 명명 시작하면 https://flywaydb.org/documentation/commandline/migrate

, 당신은 버전 이름을 중복이되지 않고 병합 '수상 누락 된 순차 번호 또는 버전 이름이 이미 병합 된 항목보다 낮은지 신경 써야합니다. How to use Flyway when working with feature branches

이슈 트래커를 사용하지 않을 때는 새로운 분기가 더 높은 서브 버전 또는 그와 비슷한 것을 얻을 수있는 다른 것을 알아낼 수 있습니다.