Liquibase를 사용하여 발에 총을 쏘지 않는 방법

이전에는 이런 일이 없었습니다. 이제 다시 시작합니다!

다음 프로젝트에서는 향후 문제를 피하기 위해 처음부터 Liquibase를 사용하기로 결정했습니다. 결과적으로 모든 젊은 팀원이 올바르게 사용하는 방법을 아는 것은 아닙니다. 내부 워크숍을 열었고, 그 내용을 기사로 만들기로 결정했습니다.

이 기사에는 관계형 데이터베이스 마이그레이션 도구, 특히 Liquibase를 사용할 때 빠질 수 있는 가장 명백한 세 가지 함정에 대한 설명과 유용한 팁이 포함되어 있습니다. 주니어 및 중급 Java 개발자를 위해 설계되었으며, 경험이 많은 개발자의 경우 이미 알려진 내용을 구조화하고 반복하는 데 흥미로울 수 있습니다.

Liquibase와 Flyway는 Java 세계에서 관계형 구조의 버전 제어 문제를 해결하기 위한 주요 경쟁 기술입니다. 첫 번째는 완전히 무료이며 실제로는 가장 자주 사용되도록 선택되므로 Liquibase가 출판의 영웅으로 선택되었습니다. 그러나 설명된 사례 중 일부는 애플리케이션 아키텍처에 따라 보편적일 수 있습니다.

관계형 구조의 마이그레이션은 관계형 데이터 저장소의 취약한 유연성을 처리하기 위한 강제적인 방법입니다. OOP 패션 시대에 데이터베이스 작업 스타일은 스키마를 한 번 설명하고 다시 건드리지 않는다는 것을 의미했습니다. 그러나 현실은 항상 상황이 변하고 테이블 구조에 대한 변경이 자주 필요하다는 것입니다. 당연히 그 과정 자체가 고통스럽고 불쾌할 수 있습니다.

프로젝트에 라이브러리를 추가하기 위한 기술 및 지침에 대한 설명은 더 깊이 다루지 않겠습니다. 이 주제에 대해 꽤 많은 기사가 작성되었습니다.

• Liquibase를 사용하여 Spring Boot 애플리케이션에서 데이터베이스 구조를 관리합니다. 1 부
• Liquibase를 사용하여 Spring Boot 애플리케이션에서 데이터베이스 구조를 관리합니다. 2 부
• Liquibase와 메이븐
• 데이터베이스 변경 버전 관리에 대한 접근 방식
• Spring MVC/Security, REST, Hibernate, Liquibase를 두 줄로 출시합니다.

또한 유용한 팁에 관한 훌륭한 기사가 이미 있습니다.

• 두통 없이 Liquibase를 사용해보세요. 실제 개발 경험에서 얻은 10가지 팁

Советы

이주 문제를 해결하는 과정에서 피와 땀, 고통을 통해 탄생한 조언과 의견을 공유하고 싶습니다.

1. 작업을 시작하기 전에 다음의 모범 사례 섹션을 숙지해야 합니다. 온라인으로 리퀴베이스

그곳에 간단하지만 매우 중요한 사항이 설명되어 있으며, 이것이 없으면 라이브러리를 사용하면 생활이 복잡해질 수 있습니다. 예를 들어 변경 세트 관리에 대한 구조화되지 않은 접근 방식은 조만간 혼란과 마이그레이션 중단으로 이어질 것입니다. 데이터베이스 구조와 서비스 로직에 대한 상호 의존적 변경 사항을 동시에 롤아웃하지 않으면 빨간색 테스트나 손상된 환경으로 이어질 가능성이 높습니다. 또한 공식 웹사이트의 Liquibase 사용에 대한 권장 사항에는 기본 마이그레이션 스크립트와 함께 롤백 스크립트의 개발 및 테스트에 대한 조항이 포함되어 있습니다. 글쎄, 기사에서 https://habr.com/ru/post/178665/ 마이그레이션 및 롤백 메커니즘에 관한 코드 예제가 있습니다.

2. 마이그레이션 도구를 사용하기 시작하면 데이터베이스 구조에서 수동 수정을 허용하지 마십시오.

속담처럼: "한 번 Persil은 영원한 Persil." 애플리케이션의 기반이 Liquibase에 의해 관리되기 시작하면 수동 변경이 즉시 일관성 없는 상태로 이어지고 변경 세트의 신뢰 수준이 XNUMX이 됩니다. 잠재적인 위험에는 데이터베이스를 복원하는 데 소요되는 몇 시간이 포함되며 최악의 경우 서버가 작동하지 않는 경우도 있습니다. 팀에 "구식" DBA 설계자가 있는 경우 조건부 SQL 개발자가 이해한 대로 데이터베이스를 편집하면 상황이 얼마나 나빠질지 인내심을 가지고 신중하게 설명하십시오.

3. 변경 세트가 이미 저장소에 푸시된 경우 편집하지 마십시오.

다른 개발자가 나중에 편집할 변경 세트를 가져와서 적용한 경우 응용 프로그램을 시작할 때 오류가 발생하면 친절한 말로 기억할 것입니다. 변경 세트를 편집하면 개발 과정에 누출이 발생하는 경우 핫픽스라는 위험한 상황을 따라야 합니다. 문제의 본질은 Liquibase의 주요 메커니즘인 해시 합계에 의한 변경 사항의 유효성 검사에 있습니다. 변경 세트 코드를 편집하면 해시 양이 변경됩니다. 변경 집합 편집은 데이터 손실 없이 전체 데이터베이스를 처음부터 배포할 수 있는 경우에만 가능합니다. 이 경우 SQL 또는 XML 코드를 리팩터링하면 반대로 작업이 더 쉬워지고 마이그레이션의 가독성이 높아질 수 있습니다. 예를 들어, 애플리케이션 시작 시 소스 데이터베이스의 스키마가 팀 내에서 합의된 상황이 있습니다.

4. 가능하다면 데이터베이스 백업을 확인하세요.

여기에서는 모든 것이 명확하다고 생각합니다. 갑자기 마이그레이션이 실패하면 모든 것을 다시 되돌릴 수 있습니다. Liquibase에는 변경 사항을 롤백하는 도구가 있지만 롤백 스크립트도 개발자가 직접 작성하므로 주요 변경 세트의 스크립트와 동일한 확률로 문제가 발생할 수 있습니다. 이는 어떤 경우에도 백업을 통해 안전하게 플레이하는 것이 유용하다는 것을 의미합니다.

5. 가능하다면 개발 시 입증된 데이터베이스 백업을 사용하세요.

이것이 계약 및 개인 정보 보호에 위배되지 않는 경우 데이터베이스에 개인 데이터가 없으며 무게는 두 태양만큼 크지 않습니다. 라이브 마이그레이션 서버에서 사용하기 전에 개발자의 컴퓨터에서 어떻게 작동하는지 확인하고 계산할 수 있습니다 마이그레이션 중 발생할 수 있는 문제가 거의 100% 해결되었습니다.

6. 팀의 다른 개발자들과 소통하세요

잘 조직된 개발 프로세스에서는 팀의 모든 구성원이 누가 무엇을 하고 있는지 알 수 있습니다. 실제로는 그렇지 않은 경우가 많으므로 작업의 일부로 데이터베이스 구조 변경을 준비하는 경우 이에 대해 전체 팀에 추가로 알리는 것이 좋습니다. 누군가 동시에 변경을 수행하는 경우 신중하게 구성해야 합니다. 처음부터가 아니라 일을 마친 후에 동료들과 소통하는 것이 가치가 있다. 변경 세트와 관련된 많은 잠재적인 문제는 코드 검토 단계에서 해결될 수 있습니다.

7. 당신이 무엇을 하고 있는지 생각해 보세요!

어떤 상황에도 적용되는 자명한 조언처럼 보일 것입니다. 그러나 개발자가 자신이 하고 있는 일과 그것이 어떤 영향을 미칠 수 있는지 다시 한 번 분석했다면 많은 문제를 피할 수 있었을 것입니다. 마이그레이션 작업에는 항상 추가적인 주의와 정확성이 필요합니다.

함정

이제 위의 조언을 따르지 않을 경우 빠질 수 있는 일반적인 함정을 살펴보고 정확히 무엇을 해야 합니까?

상황 1: 두 명의 개발자가 동시에 새로운 변경 세트를 추가하려고 합니다.

Vasya와 Petya는 서로에 대해 알지 못한 채 변경 세트 버전 4를 만들고 싶어합니다. 그들은 데이터베이스 구조를 변경하고 다른 변경 세트 파일을 사용하여 풀 요청을 발행했습니다. 다음과 같은 작용 메커니즘이 제안됩니다:

결정하는 방법

1. 어쨌든 동료들은 자신의 변경 세트가 진행되는 순서에 동의해야 합니다. 예를 들어 Petin을 먼저 적용해야 합니다.
2. 누군가는 두 번째 것을 자신에게 추가하고 Vasya의 변경 세트를 버전 5로 표시해야 합니다. 이는 Cherry Pick 또는 깔끔한 병합을 통해 수행할 수 있습니다.
3. 변경 후에는 취한 조치의 유효성을 반드시 확인해야 합니다.
   실제로 Liquibase 메커니즘을 사용하면 저장소에 두 개의 버전 4 변경 세트가 있으므로 모든 것을 그대로 둘 수 있습니다. 즉, 버전 4에 대해 서로 다른 이름을 가진 두 가지 변경 사항만 갖게 됩니다. 이 접근 방식을 사용하면 나중에 데이터베이스 버전을 탐색하는 것이 매우 어려워집니다.

또한 Liquibase는 호빗의 고향과 마찬가지로 많은 비밀을 간직하고 있습니다. 그 중 하나는 버전 1.7에 등장한 validCheckSum 키로, 데이터베이스에 저장된 내용에 관계없이 특정 변경 집합에 대해 유효한 해시 값을 지정할 수 있습니다. 선적 서류 비치 https://www.liquibase.org/documentation/changeset.html 다음과 같이 말합니다:

데이터베이스에 저장된 내용에 관계없이 이 ChangeSet에 유효한 것으로 간주되는 체크섬을 추가합니다. ChangeSet을 변경해야 하고 이미 실행된 데이터베이스에서 오류가 발생하는 것을 원하지 않을 때 주로 사용됩니다(권장 절차 아님).

예, 예, 이 절차는 권장되지 않습니다. 하지만 때로는 강한 빛의 마술사가 어둠의 기술을 마스터하기도 합니다.

상황 2: 데이터에 의존하는 마이그레이션

라이브 서버의 데이터베이스 백업을 사용할 수 없다고 가정해 보겠습니다. Petya는 변경 세트를 생성하고 로컬에서 테스트한 후 자신이 옳았다는 확신을 가지고 개발자에게 끌어오기 요청을 했습니다. 만약을 대비해 프로젝트 리더는 Petya가 이를 확인했는지 확인한 후 추가했습니다. 그러나 개발 서버에서의 배포가 중단되었습니다.

실제로 이것은 가능하며 누구도 이것으로부터 면역되지 않습니다. 이는 테이블 구조에 대한 수정 사항이 데이터베이스의 특정 데이터와 어떻게든 연결되어 있는 경우에 발생합니다. 분명히 Petya의 데이터베이스가 테스트 데이터로만 채워져 있다면 모든 문제 사례를 다루지 못할 수도 있습니다. 예를 들어, 테이블을 삭제하면 삭제되는 테이블의 레코드와 관련된 외래 키에 의해 다른 테이블의 레코드가 있음이 밝혀집니다. 또는 컬럼 유형을 변경할 때 데이터의 100%를 새로운 유형으로 변환할 수 없는 경우도 있습니다.

결정하는 방법

• 마이그레이션과 함께 한 번 사용될 특수 스크립트를 작성하고 데이터를 적절한 형식으로 가져옵니다. 이는 마이그레이션을 적용한 후 데이터를 새로운 구조로 전송하는 문제를 해결하는 일반적인 방법이지만 특별한 경우 이전에도 비슷한 방법을 적용할 수 있습니다. 물론 이 경로를 항상 사용할 수 있는 것은 아닙니다. 라이브 서버에서 데이터를 편집하는 것은 위험하고 심지어 파괴적일 수 있기 때문입니다.
• 또 다른 어려운 방법은 기존 변경 세트를 편집하는 것입니다. 어려운 점은 이미 기존 형태로 적용된 모든 데이터베이스를 복원해야 한다는 것입니다. 전체 백엔드 팀이 데이터베이스를 처음부터 로컬로 롤아웃해야 할 가능성이 높습니다.
• 그리고 가장 보편적인 방법은 데이터의 문제를 개발자 환경으로 전송하여 동일한 상황을 재현하고 손상된 것에 새로운 변경 세트를 추가하여 문제를 회피하는 것입니다.
  

일반적으로 데이터베이스 구성이 프로덕션 서버 데이터베이스와 유사할수록 마이그레이션 문제가 멀리까지 갈 가능성은 줄어듭니다. 그리고 물론 변경 세트를 저장소에 보내기 전에 어떤 문제가 발생하는지 여러 번 생각해야 합니다.

상황 3. Liquibase가 생산에 들어간 후 사용되기 시작합니다.

팀 리더가 Petya에게 프로젝트에 Liquibase를 포함하도록 요청했지만 프로젝트가 이미 프로덕션 단계에 있고 기존 데이터베이스 구조가 있다고 가정해 보겠습니다.

따라서 문제는 새 서버나 개발자 컴퓨터에서 이러한 테이블을 처음부터 다시 생성해야 하며 기존 환경이 일관된 상태를 유지하여 새 변경 집합을 수용할 준비가 되어 있어야 한다는 것입니다.

결정하는 방법

또한 여러 가지 방법이 있습니다:

• 첫 번째이자 가장 분명한 것은 새 환경을 초기화할 때 수동으로 적용해야 하는 별도의 스크립트를 갖는 것입니다.
• 두 번째는 덜 명확하며, 다른 Liquibase 컨텍스트에 있는 Liquibase 마이그레이션을 가지고 이를 적용합니다. Liquibase Context에 대한 자세한 내용은 여기에서 확인할 수 있습니다. https://www.liquibase.org/documentation/contexts.html. 일반적으로 이는 테스트 등을 위해 성공적으로 사용할 수 있는 흥미로운 메커니즘입니다.
• 세 번째 경로는 여러 단계로 구성됩니다. 먼저 기존 테이블에 대한 마이그레이션을 생성해야 합니다. 그런 다음 이를 일부 환경에 적용해야 해당 해시 합계를 얻을 수 있습니다. 다음 단계는 비어 있지 않은 서버에서 빈 Liquibase 테이블을 초기화하는 것입니다. 변경 세트 사용 내역이 있는 테이블에 데이터베이스에 이미 존재하는 변경 사항이 포함된 "마치 적용된 것처럼" 변경 세트에 대한 기록을 수동으로 넣을 수 있습니다. . 따라서 기존 서버에서는 버전 2부터 기록 카운트다운이 시작되고 모든 새 환경이 동일하게 작동합니다.
  

상황 4. 마이그레이션 규모가 커지고 완료할 시간이 없습니다.

서비스 개발 초기에는 원칙적으로 Liquibase를 외부 의존성으로 사용하며, 모든 마이그레이션은 애플리케이션이 시작될 때 처리됩니다. 그러나 시간이 지남에 따라 다음과 같은 경우가 발생할 수 있습니다.

• 마이그레이션 규모가 커지고 완료하는 데 오랜 시간이 걸립니다.
• 예를 들어 여러 데이터베이스 서버 인스턴스에서 동시에 분산 환경으로 마이그레이션해야 합니다.
  이 경우 마이그레이션을 너무 오랫동안 적용하면 애플리케이션이 시작될 때 시간 초과가 발생합니다. 또한 각 애플리케이션 인스턴스에 개별적으로 마이그레이션을 적용하면 서로 다른 서버가 동기화되지 않을 수 있습니다.

결정하는 방법

그러한 경우, 귀하의 프로젝트는 이미 규모가 크고 성인용일 수도 있으며 Liquibase는 별도의 외부 도구로 작동하기 시작합니다. 사실 Liquibase는 라이브러리로서 jar 파일로 컴파일되며 프로젝트 내에서 또는 독립적으로 종속성으로 작동할 수 있습니다.

독립 실행형 모드에서는 마이그레이션 구현을 CI/CD 환경이나 시스템 관리자 및 배포 전문가의 강력한 어깨에 맡길 수 있습니다. 이렇게 하려면 Liquibase 명령줄이 필요합니다. https://www.liquibase.org/documentation/command_line.html. 이 모드에서는 필요한 모든 마이그레이션이 수행된 후 애플리케이션을 시작할 수 있습니다.

출력

실제로 데이터베이스 마이그레이션 작업에는 더 많은 함정이 있을 수 있으며 그 중 다수에는 창의적인 접근 방식이 필요합니다. 도구를 올바르게 사용하면 이러한 함정을 대부분 피할 수 있다는 점을 이해하는 것이 중요합니다. 특히, 나는 나열된 모든 문제를 다양한 형태로 처리해야 했고, 그 중 일부는 내 실수의 결과였습니다. 물론 대부분의 경우 부주의로 인해 발생하지만 때로는 범죄가 도구를 사용할 수 없기 때문에 발생합니다.

출처 : habr.com