데이터베이스 변경 배포를 어떻게 처리합니까?

우리는 현재 데이터베이스 배포 기술에 대해 논의하고 있으며 현재 프로세스에서 최근 몇 차례의 오류가 발생했으며 배포를 롤백하려는 상황을 보았지만 이전 버전의 응용 프로그램은 새로운 버전의 응용 프로그램에 대해 테스트되지 않았습니다. 데이터 베이스.

한편으로 마이그레이션 스타일 배포가 있으며, 여기에는 버전 업 명령과 버전 다운 명령 (SQL 또는 응용 프로그램 언어로 작성되었는지 여부)이 있으며 앱은 필요한 버전을 알고 있습니다.

이것들은 간단하며 우리가 자주 롤백하지 않기 때문에 개발자는 단순합니다. 그러나 필드 / 테이블을 추가 할 때 위험이 있으며 롤백하기 전에 해당 필드가 채워집니다. 또는 이전 버전과 관련된 데이터를 삭제하는 경우가 더 나쁩니다.

다른 한편으로, 마이그레이션과 같이 롤백이 과감하지 않은 업그레이드, 롤백, 롤 포워드 방식을 고려할 수 있습니다. 예를 들어, 업그레이드는 널 입력 불가능 필드를 추가 할 수 있습니다. 롤백하면 이전 앱이 신경 쓰지 않도록 null을 허용합니다. rollforward는 널 (null) 필드를 채우고 널 (null)이 불가능한 상태로 만듭니다.

이것은 데이터를 유지하지만 코딩과 테스트가 복잡합니다 (슬프게도 자동 통합 테스트는 거의 존재하지 않으며 수정하는 동안 문제가 있습니다).

이와 관련된 문제를 완화 할 수있는 안전한 방법이 있습니까? 고려해야 할 다른 옵션이 있습니까? 나에게 고통을 덜어 줄 수있는 나쁜 경험이 있습니까?

데이터베이스 변경 사항은 다른 모든 변경 사항과 같이 처리하고 배포의 일부로 스크립트로 배포해야합니다 (물론 소스 제어에 저장 됨). 동일한 버전의 응용 프로그램에 대한 코드와 함께 배포되므로 롤백 할 대상을 정확히 알고 있습니다. 데이터베이스 스크립트를 작성할 때 각 변경 사항을 취소하기 위해 스크립트를 작성하고 스크립트를 작성할 수 있지만 롤백이 일반적이지 않은 경우에는 그렇게하지 않을 수 있습니다. 새 열이 채워지면 원래 데이터베이스로 돌아 오면 데이터가 손실됩니다.

SQL Server에서는 배포 직전에 스냅 샷을 만든 다음 배포가 실패하면 즉시 스냅 샷으로 돌아갈 수 있습니다. 이것은 사용자가 시스템에있을 때 배포가 일어나지 않는다고 가정합니다 (데이터 변경 사항을 잃고 싶지는 않음). 업그레이드를 수행하기 위해 전체 시스템을 일시적으로 중단해야하는 주요 릴리스 동안 가장 유용합니다. 또는 여전히 스냅 샷을 작성하고 스냅 샷과 데이터베이스 간 데이터베이스 비교를 수행하여 롤백이 필요한 경우 차이점을 확인할 수 있습니다. SQLCompare와 같은 도구는 코드를 생성하여 스냅 샷 구조로 돌아갈 수도 있습니다. 다른 데이터베이스에서 사용할 수있는 것이 무엇인지 모르겠습니다.

데이터베이스 구조의 변경은 테스트 환경을 사용하여 자동화 / 스크립트로 작성하고 테스트해야합니다. 프로덕션 환경에서 수동 변경이 너무 위험

합리적인 롤백 전략 (일이 나빠질 확률이 가장 낮은 전략)은 업그레이드 전 스냅 샷으로 돌아가는 것입니다. 문제가 발생하면 스냅 샷으로 돌아갈 수 없을 정도로 빨리 발생하거나 롤백하기에는 너무 늦습니다 (데이터베이스 문제로 인해 다음 주말 보고서 실패).

변경은 필드 추가와 같이 점진적으로 수행 할 수 있으므로 한 번에 모두 수행 할 때보 다 적은 위험으로 실시간 테스트됩니다.

계획을 통해 각 릴리스마다 소프트웨어 및 데이터베이스 업그레이드 에 직면하지 않고 데이터베이스를 변경하여 다음 릴리스를 지원할 수 있습니다.

소프트웨어 업그레이드 인 경우와 마찬가지로 데이터베이스 업그레이드 후 며칠 동안 비상 모드 상태 가되도록 준비하십시오 .

문제를 수동으로 패치하려는 충동에 저항하십시오. 비상 전략 (롤백, 스냅 샷)을 사용하고 업그레이드를 다시 시도하기 전에 문제가 발생한 이유를 고려하십시오.