요약하자면, MS는 production에서 migration을 할 때는 dotnet ef 도구로 SQL Script를 추출하여 DB에 적용하는 방법을 추천하고 있습니다.
그리고 donet ef 도구로 만들어진 migration 코드는 오류가 있을 수 있으므로 반드시 적용 결과를 확인하라고 안내하고 있습니다.
Whatever your deployment strategy, always inspect the generated migrations and test them before applying to a production database. A migration may drop a column when the intent was to rename it, or may fail for various reasons when applied to a database.
위 시나리오로 생각했을 때 migration 순서는 다음과 같지 않을까요?
서버 중단
SQL Script 반영
서버 이미지 변경
서버 시작
쉽게 해결하는건 context.Database.Migrate() 코드를 사용하는 것이며 MS는 추천하지 않고 있습니다.
Warning
Carefully consider before using this approach in production. Experience has shown that the simplicity of this deployment strategy is outweighed by the issues it creates. Consider generating SQL scripts from migrations instead.
Don’t call EnsureCreated() before Migrate(). EnsureCreated() bypasses Migrations to create the schema, which causes Migrate() to fail.
무중단은 저도 경험이 미천하여 아이디어로 떠오르는건 DB 2개와 서버 2개를 준비하고 하는 방법만 떠오르네요…
질문에 대한 답변으로는 조금 결이 틀리겠지만…
저 같은 경우는 SQL SERVER를 리눅스 도커에서 사용중입니다.
그리고, efcore를 사용하지 않는 중입니다.
sql database project로 변경사항을 적용하는 방법을 사용중입니다.
제 경우엔 이 방법이 작업하기 편했습니다.