플라이웨이에서 마이그레이션을 스쿼시/병합하는 방법
마이그레이션 스크립트가 있다고 가정해 보겠습니다.V1_1
로.V1_300
그것은 꽤 큰 숫자이고 매우 오랜 시간이 걸립니다.그러나 때때로 릴리스가 있습니다. 플라이웨이의 관점에서 모든 마이그레이션을 병합할 수 있습니까?
- 모든 마이그레이션
V1_1
로.V1_300
하나의 파일(예:V2_1
) - 이러한 마이그레이션에 소요되는 시간 감소
중복 여부를 수동으로 확인하는 것은 정말 시간이 많이 걸립니다.당신의 답변에 미리 감사드립니다.
제 프로젝트에서도 같은 문제가 발생하여 이미 프로덕션에 배포된 버전의 롤업을 수행하기로 결정했습니다.증분 변경 사항을 하나의 파일로 롤업하기 위해 데이터베이스에서 마이그레이션을 처음부터 실행한 다음 전체 데이터베이스를 하나의 SQL 파일에 덤프(내보내기)했습니다.마지막 마이그레이션 버전을 사용하여 파일 이름을 지정했습니다.당신의 경우에는V1_300__rollup.sql
그런 다음 새 버전을 계속 추가할 수 있습니다.V2_1
,V2_2
등을 반복하고 롤업을 원할 때 반복합니다.
비슷한 문제가 있었습니다. DB 마이그레이션 스크립트가 너무 많아 테스트 실행이 느립니다.또한 애플리케이션을 실행하기에는 매우 복잡한 환경이 있습니다. 빈 도커 DB에 대해 모든 테스트가 실행되고 있으며, DB 버전이 서로 다른 여러 배포(dev - 최신, stage - some, prod - oldest)가 있습니다.
dev/stage/prod의 모든 버전이 정렬된 경우와 dev/stage가 prod보다 앞선 경우 두 가지 경우가 있습니다.아래에서는 모든 환경에서 동일한 DB 버전을 사용하는 경우의 해결 방법을 설명하겠습니다.
두 번째 사례도 해결이 가능하지만 구현을 위해 더 많은 노력이 필요합니다.일반적인 접근 방식 - DB 스키마를 "가장 오래된" DB 버전까지 병합하고, 최신 마이그레이션 스크립트의 이름을 주요 버전 이후에 새 버전으로 바꾸고, 최신 DB 변경사항이 두 번 적용되지 않는지 확인합니다(변경사항이 이미 적용되었는지 확인).
"모든 envs DB 버전 정렬" 단계:
- 병합된 DB 스크립트를 작성합니다.빈 DB에 대해 프로젝트를 실행하고 DB 유형별 도구를 사용하여 거기서 스키마를 추출할 수 있습니다.
- 구성된 이동 경로 위치에서 모든 DB 마이그레이션 스크립트 파일을 삭제(또는 이동)하고 이전 단계에서 생성된 파일로 대체합니다.최신 V1_300이 있으면 병합된 파일에 V2_0이 포함되도록 새 메이저 버전을 생성하는 것이 좋습니다.
- V2_0 스크립트 위치와 동일한 Validate.sql 앞에 콘텐츠(예: MSSQL/AzureSQL)를 생성합니다(플라이웨이 문서 참조).
-- run baseline manually
if OBJECT_ID(SCHEMA_NAME() + '.flyway_schema_history', 'U') IS NOT NULL
if exists(select 1
from flyway_schema_history
where version = 'YOU_FIRST_MIGRATION_VERSION_AFTER_BASELINE')
begin
begin
declare @max_inst_rank int;
select @max_inst_rank = MAX(installed_rank) from flyway_schema_history;
delete from flyway_schema_history;
INSERT INTO flyway_schema_history (installed_rank, version, description, type, script, checksum,
installed_by,
installed_on, execution_time, success)
VALUES (@max_inst_rank + 1, 'YOUR_MERGED_VERSION', '<< Flyway Baseline >>', 'BASELINE', '<< Flyway Baseline >>', NULL,
'WHO_CREATED', GETDATE(), 0, 1);
end;
end;
GO
위치:
YOU_FIRST_MIGRATION_VERSION_AFER_BASELINE - 기준선 후 첫 번째 마이그레이션 수(예: 1.0.1)
YOR_MERGED_VERSION - 새로운 "MERGED" 버전의 수(예: 2.0.0)
WHO_CREATED - 레코드를 만든 사용자
이 스크립트는 플라이웨이가 마이그레이션 파일에 대해 마이그레이션 DB 레코드의 유효성을 검사하기 전에 실행되므로 다음 작업을 수행합니다.
- flyway_schema_history가 존재하지 않는 경우(빈 DB에서 실행 중) - dong nothing
- flyway_flyway_history가 존재하는 경우
- 첫 번째 합니다. - records " " " " (삭제: 1.0.1) " 입니다. 모든 레코드 삭제
에서 "flyway새 0.flyway_proxy_history로 합니다. DB 않습니다. DB는 DB입니다. - 첫 번째 마이그레이션 1.0.1은 존재하지 않습니다. 이미 필요한 작업을 모두 수행했으므로 아무것도 수행하지 마십시오.
이 모든 작업을 수행하고 모든 환경에 배포하면 Flyway_schema_history 테이블에 V2.0.0 파일과 하나의 BASERINE 레코드가 표시됩니다.버전 V2.0.1부터 새 DB 완화 스크립트를 생성할 수 있습니다.
감사 목적으로 삭제하는 대신 flyway_schema_history 테이블 레코드를 다른 테이블로 이동할 수도 있습니다.
유효성 검사 전.sql 스크립트는 각 서버 시작 시 실행되며 모든 변경 사항이 이미 적용되었기 때문에 일반적으로 아무것도 수행하지 않습니다.모든 환경이 업그레이드될 때 플라이웨이 폴더에서 스크립트를 제거할 수 있습니다.
플라이웨이 8.5.x, SpringBoot 2.7.x에서 검증됨
언급URL : https://stackoverflow.com/questions/25506192/how-to-squash-merge-migrations-in-flyway
'programing' 카테고리의 다른 글
사용자 정의 로그인 양식.JSON 응답을 가져오도록 Spring 보안 구성 (0) | 2023.07.10 |
---|---|
특정 커밋 이후 커밋을 어떻게 나열합니까? (0) | 2023.07.10 |
Entity Framework로 작업할 때 좋은 설계 방법은 무엇입니까? (0) | 2023.07.10 |
plot.new()에 오류가 있습니다. : R에서 그림 여백이 너무 큽니다. (0) | 2023.07.10 |
vuex 상태가 변경 시 UI를 업데이트하지 않음 (0) | 2023.07.10 |