db:check-migrations 작업
이 작업은 Merge Request 파이프라인의 테스트 단계에서 실행됩니다. 다음을 확인합니다:
- 새로운 마이그레이션을 롤백한 후, 작성자의 작업 브랜치와 대상 브랜치 간의 스키마 덤프 비교합니다. 이 체크는 이 새로운 마이그레이션을 실행하기 전의 스키마로 올바르게 재설정되었는지를 확인합니다.
- 작성자가 커밋한
db/structure.sql
파일과 작업 브랜치 간의 스키마 덤프 비교합니다. 이 체크는 마이그레이션에서 예상한 변경 사항이 모두 포함되어 있는지 확인합니다. - 작성자가 커밋한
db/schema_migrations
와 마이그레이션을 실행한 후에 스크립트가 생성한db/schema_migrations
간의 Git 차이를 비교합니다. 이 체크는 모든 것이 올바르게 커밋되었는지 확인합니다.
문제 해결
거짓 긍정 결과
이 작업은 일부 거짓 긍정 결과를 반환할 수 있기 때문에 실패해도 괜찮습니다.
예를 들어, 열을 삭제한 다음 롤백하면 해당 열은 항상 열 디렉터리의 마지막에 다시 추가됩니다. 열이 이전에 디렉터리 중간에 있었을 경우 롤백이 스키마를 이전 상태로 정확하게 되돌릴 수 없습니다. 작업은 실패하지만 수용할 수 있는 상황입니다.
실제 사례에 대해서는 이 실패한 작업을 참조하세요. 여기서 작성자는 position
열을 삭제했습니다.
롤백 후 스키마 덤프 비교가 실패하는 경우
이 실패는 작업 브랜치가 대상 브랜치보다 뒤처지는 경우에 종종 발생합니다. 다음은 실제 시나리오입니다:
-
main
대상 브랜치에서dev
작업 브랜치를 체크아웃합니다. 이 시점에서 각 브랜치의HEAD
는 커밋 A에 있습니다. - 누군가
main
브랜치에서 작업을 하고fk_rails_dbebdaa8fe
제약 조건을 제거하여main
에 커밋 B를 만듭니다. -
dev
브랜치에dependency_proxy_size
열을 추가합니다. -
dev
브랜치의 CI/CD 파이프라인에서db:check-migrations
작업이 실패합니다.structure.sql
파일이 예상 상태로 롤백되지 않았기 때문입니다.
이것은 브랜치 dev
가 커밋 A와 C를 포함하고 있었기 때문에 발생했습니다. 데이터베이스 스키마는 fk_rails_dbebdaa8fe
제약 조건이 삭제된 것을 알지 못했습니다. 두 스키마를 비교할 때 dev
브랜치는 이 제약 조건을 포함하고 있었지만 main
브랜치는 포함하고 있지 않았습니다.
이 예는 실제로 발생한 사례입니다. 작업 실패 로그를 참조하세요.
이러한 문제를 해결하기 위해서는 작업 브랜치를 대상 브랜치 위에 리베이스하여 최신 변경 사항을 가져와야 합니다.