TYPEORM MIGRATION

마이그레이션 시간 순서

TypeORM의 entity는 현재 코드의 모양이고 migration은 이미 배포된 데이터베이스가 지나가야 할 단계다. generate, run, revert를 단순 명령으로 외우면 운영에서 schema drift, 잠금, 롤백 불가 변경을 놓치기 쉽다.

01

차이 추출

현재 entity metadata와 연결된 DB schema를 비교해 변경 SQL 초안을 만든다.

잘못된 연결이면 엉뚱한 기준으로 생성된다
02

SQL 검토

컬럼 drop, nullable 변경, index 재생성, default 값이 데이터에 미치는 영향을 읽는다.

자동 생성 SQL은 의도 설명을 모른다
03

데이터 보정

스키마 변경 전후로 필요한 backfill, 중복 제거, FK 정리를 migration에 포함한다.

DDL만으로 끝나지 않는 변경이 많다
04

적용 제어

트랜잭션 지원, 잠금 시간, 배포 순서를 환경별로 나눠 확인한다.

큰 테이블 index는 서비스 지연을 만들 수 있다
05

되돌림 검토

revert가 데이터 손실 없이 가능한지, 아니면 별도 복구 절차가 필요한지 문서화한다.

drop 이후의 rollback은 코드만 되돌려서 해결되지 않는다
generate
초안 생성 entity와 실제 DB 기준이 정확해야 의미 있는 SQL이 나온다.
empty diff면 datasource와 naming strategy를 본다
run
순차 적용 이미 실행된 migration table을 기준으로 남은 단계만 적용한다.
수동 변경은 drift를 만든다
revert
마지막 단계 되돌림 down SQL이 데이터 보존을 보장하는지 별도로 판단한다.
drop column은 되돌려도 값이 없다
drift
코드와 DB 불일치 운영 DB에 직접 넣은 index, constraint, enum 변경을 추적한다.
다음 generate가 예기치 않은 SQL을 만든다

적용 전 확인

SQL 리뷰 자동 생성 파일에서 destructive DDL과 긴 lock 가능성을 먼저 표시한다.
스테이징 실행 운영과 가까운 데이터량에서 실행 시간과 실패 지점을 측정한다.
복구 경로 revert, 백업 복원, forward fix 중 어떤 선택지가 실제 가능한지 정한다.