Publish가 프로덕션 데이터베이스를 업데이트하는 방법

Replit이 관리하는 데이터베이스를 사용하는 앱을 게시하면, Replit이 프로덕션 데이터베이스를 개발 데이터베이스와 일치하도록 대신 업데이트합니다. 마이그레이션을 직접 작성하거나 실행할 필요가 없습니다. 게시하는 동안 Replit은 다음을 수행합니다.

1. 개발 데이터베이스와 프로덕션 데이터베이스의 스키마를 비교합니다.
2. 프로덕션을 개발과 일치시키는 데 필요한 SQL을 생성합니다.
3. 열 이름 변경처럼 모호한 부분을 해결하도록 요청합니다.
4. 프로덕션 데이터베이스의 복사본에 대해 SQL을 검증합니다.
5. 앱 빌드가 끝난 후, 새 버전이 라이브로 전환되기 전에 프로덕션에 SQL을 적용합니다.

​

1단계: Replit이 변경 사항 감지

게시는 Provision 단계로 시작합니다. 개발 스키마가 프로덕션과 다르면 Publish 창에 Development database changes detected가 표시되고 마이그레이션 생성이 시작됩니다. 게시할 때는 테이블, 열, 인덱스, 제약 조건, 뷰, enum, 시퀀스, 행 수준 보안 정책이 마이그레이션됩니다. 일부 객체는 이전되지 않습니다. 지원되지 않는 데이터베이스 객체를 참고하세요.

​

2단계: 모호한 변경 사항에 대한 질문에 답하기

일부 스키마 변경은 두 가지 다른 의미일 수 있습니다. Replit이 의도를 판단할 수 없으면 Detected potential conflicts, please review라는 메시지와 함께 일시 중지하고 선택을 요청합니다. 옵션을 선택하고 Submit을 선택하세요.

​

이름 변경인가요, 새로 만든 건가요?

같은 테이블에서 열 하나가 제거되고 다른 열이 추가되면, Replit은 기존 열의 이름이 변경된 것인지 묻습니다.

• Yes, rename column은 기존 데이터를 새 이름으로 유지합니다.
• No, create new column은 빈 열을 추가하고 기존 열을 데이터와 함께 삭제합니다.

테이블, enum, 시퀀스, 뷰, 스키마에서도 같은 질문이 나타납니다.

​

데이터가 있는 테이블의 고유 제약 조건

프로덕션에 이미 행이 있는 테이블에 고유 제약 조건을 추가하면, Replit이 제약 조건이 확인할 행의 수를 알려줍니다.

• Add the constraint as-is는 기존 행 중 하나라도 제약 조건을 위반하면 마이그레이션이 실패합니다. 그 후 데이터를 수정하고 다시 게시할 수 있습니다.
• Remove all rows, then add the constraint는 먼저 테이블을 비웁니다. 다른 테이블이 외래 키로 이 테이블을 참조하는 경우에는 이 옵션이 제공되지 않습니다.

​

3단계: 생성된 SQL 검토

모든 질문에 답하고 나면, 창에 Replit이 실행할 정확한 SQL과 함께 Generated migrations to apply to production database가 표시됩니다. 계속하기 전에 읽어보세요. 다음 두 가지 신호는 마이그레이션에 추가적인 주의가 필요함을 알려줍니다.

• 데이터 손실 경고. 프로덕션에 행이 있는 테이블에서 데이터를 제거할 수 있는 변경이 있으면 창이 주황색으로 바뀌고, 영향을 받는 각 테이블이 행 수와 함께 나열됩니다. 다음과 같은 변경이 이를 발생시킵니다.
  • 열 또는 테이블 제거 또는 재생성
  • 열의 타입 또는 값 필수 여부 변경
  • 필수 열 추가
  • 인덱스 및 제약 조건 추가 또는 재생성
• 다운타임 알림. 변경 사항이 현재 실행 중인 앱 버전과 호환되지 않으면, 변경 도중 사용자가 데이터베이스에 쓰지 못하도록 Replit이 마이그레이션을 적용하기 전에 실행 중인 앱을 중지합니다. 자세한 내용은 **What’s happening?**을 펼쳐 확인하세요.

​

4단계: Replit이 마이그레이션 검증

Replit은 프로덕션 데이터베이스의 임시 복사본을 만들고 그 위에서 SQL을 실행합니다. 창에는 **Validating database migrations…**가 표시된 후 Database migrations validated successfully가 표시됩니다. 복사본에서 SQL이 실패하면 창에 데이터베이스 오류와 함께 Migrations failed validation, please review가 표시되며 세 가지 해결 방법이 제공됩니다.

​

5단계(선택 사항): 마이그레이션된 복사본에서 앱 미리 보기

검증이 성공하면 Create preview deploy를 선택하여 마이그레이션된 프로덕션 복사본을 대상으로 앱을 빌드할 수 있습니다. 빌드가 끝나면 View preview를 선택하여 엽니다. 프리뷰를 사용하여 스키마 변경이 영향을 주는 앱의 부분을 직접 클릭해 보세요. 프리뷰는 복사된 데이터를 사용하므로 그곳에서 하는 어떤 작업도 프로덕션에 영향을 주지 않습니다. 프리뷰는 생성 후 2시간 뒤에 만료됩니다. 더 많은 시간이 필요하면 새로 만드세요.

​

6단계: 승인 및 게시

계속하려면 Approve and publish를 선택하세요. Replit은 검토한 정확한 SQL을 게시 요청과 함께 전송하므로, 여러분이 본 내용이 그대로 실행됩니다. 그런 다음 게시는 나머지 단계를 거쳐 진행됩니다. 마이그레이션은 앱 빌드가 끝난 후 새 버전이 승격되기 전에 실행됩니다.

1. 보안 검사
2. 빌드
3. 프로덕션에 데이터베이스 마이그레이션 적용
4. 새 버전 번들링 및 승격

Replit이 이 시점에 마이그레이션을 적용하므로, 앱의 빌드 명령이나 시작 코드는 데이터베이스 스키마를 절대 변경해서는 안 됩니다. 배포 빌드 명령이나 서버의 진입점에 drizzle-kit push, db:push, CREATE TABLE IF NOT EXISTS 문을 추가하지 마세요. 이들은 위의 검토와 검증 과정 밖에서 게시할 때마다 실행됩니다. Publish 창을 사용하는 대신 Agent에게 다시 게시하도록 요청했는데 개발 스키마와 프로덕션 스키마가 다르면, 다시 게시가 차단되고 마이그레이션을 검토하도록 Publish 창으로 안내됩니다.

​

프로덕션을 수동으로 변경하기

일회성 수정의 경우 Database 창에서 프로덕션에 직접 SQL을 실행할 수 있습니다. 데이터베이스 전환기에서 Production을 선택한 다음 SQL 콘솔을 사용하세요. 데이터로 작업하기를 참고하세요. Replit은 스키마 파일이 아니라 항상 실제 데이터베이스를 비교하므로, 수동 변경은 다음 게시의 비교에 포함됩니다. 개발 환경에는 없는 열을 프로덕션에 직접 추가하면, 다음 게시에서 해당 열을 삭제하도록 제안합니다.

​

다음 단계

• 개발 및 프로덕션 데이터베이스: 두 데이터베이스가 어떻게 다른지 이해합니다.
• 데이터 복구: 개발 또는 프로덕션 데이터를 복원합니다.
• 지원되지 않는 데이터베이스 객체: Publish가 마이그레이션할 수 없는 객체입니다.