오래된 마이그레이션 파일은 여러 가지 이유로 쓸모가 없습니다.
오래된 마이그레이션이 쓸모없는 이유
-
실행 불가능성: 데이터베이스 스키마는 시간이 지남에 따라 크게 진화하므로, 오래된 마이그레이션은 현재 환경(Rails 버전, Gem, DB 버전 등)과 맞지 않아 실패할 가능성이 높습니다. 이전 마이그레이션이 성공하지 못하면 외래 키 제약 조건이나 컬럼 타입이 잘못될 수 있으며, 마이그레이션 오류를 디버깅하는 데 많은 시간이 소요됩니다.
-
초기부터 실행할 일 없음: 프로덕션 환경에서
rails db:drop db:create db:migrate를 처음부터 실행하는 경우는 거의 없습니다. 대신 더 빠르고 신뢰할 수 있으며 과거 마이그레이션 체인에 의존하지 않는db:schema:load또는db:structure:load를 사용합니다. “0부터 애플리케이션을 실행 가능하게 유지하는 것”은 잘못된 공학적 관행입니다. -
환경 불일치: 과거 마이그레이션이 완벽하게 작동했던 2018년의 Rails 5.2 및 PostgreSQL 10 환경은 Rails 7.2 및 PostgreSQL 16과 같은 현재 환경에서 예상치 못한 오류를 일으킬 수 있습니다. 마이그레이션 내에서 애플리케이션 코드나 Gem을 사용하는 경우, 해당 코드가 현재 존재하지 않거나 변경되어 문제가 발생할 수 있습니다.
-
역사 기록은 Git으로: 마이그레이션 파일은 단지 특정 시점의 변경 사항을 기록한 구현 세부 사항일 뿐입니다. 스키마의 진화 과정이나 과거 기록은 Git을 통해 충분히 추적할 수 있습니다.
오래된 마이그레이션 삭제 방법
-
schema.rb커밋:rails db:schema:dump를 실행하여schema.rb를 최신 상태로 만들고 커밋합니다. 이것이 현재 데이터베이스의 진정한 소스입니다. -
기준 설정 및 삭제: 개발 활동에 따라 지난 6-12개월간의 마이그레이션만 남기고, 그보다 오래된 파일은 삭제합니다. 다음 Git 명령어를 사용하여 오래된 파일을 찾아 삭제할 수 있습니다.
bash git ls-tree -r --name-only HEAD | grep "^db/migrate/" | while read file; do last_commit=$(git log -1 --format="%ct" -- "$file") cutoff=$(date -v-180d +%s) # 6개월 (180일) 기준 if [ "$last_commit" -lt "$cutoff" ]; then echo "$file" fi done | xargs -I {} git rm {} git commit -m "Delete old migrations - schema.rb is the source of truth"### 심리적 장벽 및 예외
-
심리적 장벽: 스키마 진화 과정을 이해하는 데 필요할 것이라는 생각은 오해입니다. 현재 상태는
schema.rb로, 역사는 Git 기록으로, 비즈니스 로직은 모델과 테스트로 확인해야 합니다. -
프로덕션 배포: 새로운 프로덕션 서버에 배포할 때도
rails db:schema:load또는rails db:structure:load를 사용하여 데이터베이스를 생성하므로, 오래된 마이그레이션 실행은 필요하지 않습니다. -
유일한 예외: Gem이 자체 마이그레이션을 설치하는 경우입니다. 이러한 Gem은 스키마 업그레이드를 위해 마이그레이션을 생성할 수 있으므로, 해당 마이그레이션은 유지하는 것이 좋습니다.