마이그레이션: 스키마를 안전하게 바꾸기

당신의 스키마는 변한다 — 컬럼을 추가하고, 테이블 이름을 바꾸고, 인덱스를 추가하게 된다. 마이그레이션은 그런 변경 하나를 기술하는 버전 관리되고 반복 가능한 스크립트다. 마이그레이션이 중요한 이유는, 당신의 노트북, 동료의 노트북, 그리고 프로덕션의 스키마가 동일하게 유지되어야 하기 때문이다.

마이그레이션을 안전하게 지키는 규칙:

• 프로덕션에서 데이터베이스를 손으로 절대 수정하지 말라. 마이그레이션을 작성하라.
• 마이그레이션은 앞으로 나아간다. 각각이 새 파일이며, 이미 실행된 옛것을 다시 쓰지 않는다.
• 파괴적 변경은 신중히 하라. 컬럼이나 테이블을 드롭하면 데이터가 영구히 삭제된다. 먼저 백업을 가져라.
• 추가하는 변경이 가장 안전하다. nullable 컬럼을 추가하는 것은 거의 아무것도 깨뜨리지 않지만, 이름을 바꾸거나 제거하는 것은 실행 중인 코드를 깨뜨릴 수 있다.

Prisma, Drizzle, 또는 Rails 마이그레이션 같은 도구가 이것들을 생성하고 추적해준다. 도구에게 맡겨라.

마이그레이션은 두 부분으로 이루어진다: 적용할 변경(up)과 그것을 되돌리는 법(down). 신뢰할 만한 도구는 둘 다 생성해주어, 잘못된 배포가 깔끔하게 롤백될 수 있다:

-- up: 선택적 bio 추가, 라이브에서 적용해도 안전
ALTER TABLE users ADD COLUMN bio TEXT;

-- down: 되돌리기
ALTER TABLE users DROP COLUMN bio;

정말로 위험한 마이그레이션은 이름 변경과 타입 변경인데, 옛 코드와 새 스키마가 잠시 어긋나기 때문이다. 프로페셔널한 패턴은 그것들을 추가적 단계로 쪼개는 것이다: 새 컬럼을 추가하고, 백필하고, 코드가 그것을 읽도록 전환한 다음, 아무것도 참조하지 않게 된 나중의 배포에서야 옛 컬럼을 드롭한다. 느리게 느껴지지만, 매끄러운 릴리스와 배포 도중 모든 사용자에게 터지는 500 에러 급증 사이의 차이다.