본문 바로가기
Study/지속적인 통합

[지속적인 통합] 5장. 지속적인 데이터베이스 통합

by Nahwasa 2023. 3. 12.

지속적인 통합 스터디 메인 페이지

목차

    * 주의 : 책(폴M 듀발 저 - 지속적인 통합) 내용 중 기억하고 싶은 내용 및 제 생각을 적은 글 입니다. 책이 나온지 오래되어 설명에 나온 기술스택이 현재 사용되지 않는게 많아 기술스택보다는 이론이나 책의 조언들 위주로 작성할 것 같고, 기술스택은 제가 알고있는대로 수정해서 작성합니다. 따라서 책에서 말하고자 하는 바와 다를 수 있습니다.

    * 별도로 표기되어 있지 않다면 이미지 출처는 '지속적인 통합 (폴M 듀발 저)' 책 입니다.

     

     

    CHAPTER 5. 지속적인 데이터베이스 통합

    • 개발 생명주기 내내 소스 코드와 DB가 완전히 '별세계'에서 따로 노는 것 같은 느낌을 받은 적 없나요?
    • 지속적인 데이터베이스 통합
      • 변경 사항이 커밋될 때마다 DB와 테스트 데이터를 다시 빌드하는 과정
    • 데이터베이스 코드(DDL, DML, 설정 파일 등)도 본질적으로 시스템 내의 다른 소스 코드와 다르지 않다.

     

     

    데이터베이스 통합을 자동화하기

    • 데이터베이스 관련 업무를 자동화해 놓으면, DB를 삭제하고 만든 다음 테스트 데이터를 넣는 것만으로도 문제를 해결하는 모습을 발견하게 된다.

     

    • 반복적인 데이터베이스 통합 활동
      • DB 삭제하기
      • DB 만들기
      • 시스템 데이터 삽입하기 : 소프트웨어를 전달할 때 시스템에 포함시켜야 할 모든 초기 데이터를 삽입
      • 데스트 데이터 삽입
      • 데이터베이스와 데이터 이전하기 : DB 스키마와 데이터를 주기적으로 이전
      • 다양한 환경에 DB 인스턴스를 설치하기 : 다양한 버전과 환경을 지원하기 위해 별도의 DB 설치
      • 칼럼 특성과 제약조건을 수정하기
      • 테스트 데이터를 수정하기 : 다양한 환경에 맞춰 테스트 데이터를 개정
      • 저장 프로시저, 트리거, 함수 수정
      • 다양한 환경에 대한 접근 권한 얻기 : 동일한 ID, 암호, DB 식별자를 사용해 다양한 DB 환경에 로그인
      • 대용량 데이터 집합을 백업하고 복원하기

     

    • 다시 사용할 수 있는 스크립트를 만드세요
      • 스프링부트에서도 간단하게는 schema.sql, data.sql로 처리 가능.

     

     

    로컬 데이터베이스 샌드박스를 사용하기

    • 공유 DB가 하나 뿐일 경우 공유 개발 DB를 변경할 때 다른 사람에게 부정적인 영향을 끼칠 수 있다.

     

    • 개발자가 자신만의 로컬 '데이터베이스 샌드박스'도 가진다면 위의 상황을 피할 수 있다.
      • 메모리 DB이고, 의존성 하나 추가하면 쓸 수 있는 H2 DB 혹은 docker를 사용하면 편하게 가능할 것 같다. 

     

     

    VCS를 사용해서 DB 자산 공유하기

    • 코드처럼 DB 통합 스크립트 등도 VCS를 통해 공유하자.
      • 제약조건과 트리거를 포함한 테이블과 뷰를 삭제하고 만들기 위한 DDL
      • 저장 프로시저와 함수
      • 개체-관계 다이어그램
      • 다양한 환경을 위한 테스트 데이터
      • 특정 데이터베이스 설정값

     

    • 일단 모든 DB 자산을 VCS에 적용해놓으면, 데이터베이스 변경 내역 또한 히스토리를 가지게 된다.
      • 상황에 따라 이전 DB에서 돌려볼 수 있다.
      • flyway 같은걸 써도 좋을 것 같다.

     

     

    지속적인 데이터베이스 통합

    • 데이터베이스 통합 프로세스를 자동화하고 공유하고 빌드하자.
      • 그래야 이러한 프로세스를 지속적이게 만들 수 있다.

     

    • 각 개발자는 어떤 DB 스크립트라도 고칠 수 있는 권한이 있어야 한다.
      • DBA 병목 현상 감소
      • 개발자가 필요한 일을 할 수 있음.
      • DBA는 빌드가 깨ㅔ졌을 때 개발자와 상의할 수 있음.
      • 물론 추가적인 권한에는 추가적인 책임이 따른다. 변경한 코드를 커밋하기 전에 철저히 테스트해야 할 책임이 있다.

     

    • DBA를 개발 팀의 일원으로 만들기

     

    • DB 또한 코드와 같다. DB 통합 때문에 빌드가 깨진다면 깨진 빌드를 고치는 것이 최우선이다. 테스트, 검사, 피드백도 필요하다.

     

     

    질문

    • 자동화된 빌드 프로세스를 써서 데이터베이스를 다시 만들어낼 수 있습니까? "버튼 하나만 누르면" 데이터베이스를 다시 빌드할 수 있나요?
    • 데이터베이스 통합 자동화에 관련된 스크립트(빌드 및 SQL)를 버전 관리 저장소에 커밋해넣습니까?
    • 프로젝트 구성원 모두가 자동화된 빌드 프로세스를 써서 데이터베이스를 다시 만들어낼 수 있습니까?
    • 개발 도중에 버전 관리 저장소를 사용하여 이전 버전의 데이터베이스로 되돌아갈 수 있습니까?
    • 데이터베이스 통합 프로세스가 지속적입니까? 변경한 코드를 버전 관리 저장소에 적용할 때마다 소프트웨어 코드 변경 내역이 최신의 데이터베이스 코드와 함께 통합되고 테스트됩니까?
    • 테스트를 돌려서 데이터베이스 저장 프로시저나 트리거의 행동을 검증합니까?
    • 자동화된 데이터베이스 통합 프로세스의 설정을 쉽게 바꿀 수 있습니까? 사용자 아이디, 유일한 데이터베이스 식별자, 테이블 공간 크기 및 기타 사항을 하나의 설정 파일만으로 수정할 수 있나요?

    댓글