DB 스키마 변경과 코드 배포가 공존하는 파이프라인의 문제점
여기서 DB 스키마 변경은 테이블 생성, 삭제, 컬럼 수정 등을 의미함

테이블이 있어야 CRUD가 가능하므로 migrate -> 코드 반영 순이 맞는 것처럼 보임
프로젝트 초기엔 거의 테이블 생성만 하므로 문제가 발생하지 않음
하지만 문제가 있음

코드가 DB 테이블, 컬럼에 접근하지 못하는 문제

안쓰는 테이블이나 컬럼을 먼저 삭제하면 배포되는 동안 예전 코드가 테이블이나 컬럼에 접근해서 문제 생김

로컬, 개발(테스트) 서버에서는 DB 변경 -> 코드 배포 순으로 진행을 해도 테이블에 접근하는 요청이 없으면 문제를 발견할 수 없지만
요청이 많은 상용 서버에서는 문제가 발생하기 쉬움

그럼 코드를 먼저 배포하고 마지막에 DB 스키마 변경을 하면 문제가 해결될까?
상황에 따라 문제가 없을 때도 있지만
신규 API를 배포하고 유저가 CRUD 요청을 보내는데 아직 DB 스키마 변경이 되지 않았다면 여전히 문제가 생긴다

결론

Migrate -> 코드 반영, 코드 반영 -> migrate는 상황에 따라 선택해야하므로 배포 파이프라인에 migrate 명령어를 넣으면 안됨

해결 방법은 두 가지 방법 중 적합한 방법을 로컬, 개발, 스테이징 등 운영 서버가 아닌 곳에서 시도하고 운영서버에 반영한다

1. 코드 반영 -> 수동 migrate
   더 이상 쓰지 않는 테이블, 컬럼을 제거할 때, 이것들을 참조하지 않도록 코드를 정리하고 DB 스키마 변경을 한다. 먼저 테이블, 컬럼을 없애면 코드에서 에러남.

2. 수동 migrate -> 코드 반영
   서버 입장에서 클라이언트가 계속 호출하는 코드라면 호환성이 유지되게 테이블 생성, 수정을 먼저 하고 코드 배포를 한다. 코드를 먼저 반영하면 CRUD할 테이블, 컬럼이 없어서 문제 생기는 경우.