안녕하세요. 제가 알기로 DB의 테이블 구조 변경을 감지할 수 있는 도구는 없는 것으로 알고 있습니다. 제가 모를 수도 있고요. 만약 DB와 소스 코드의 상태가 불일치하는지 파악해야 한다면 데이터 접근 로직(DAO와 같은 클래스)을 담당하는 클래스에 대한 자동화된 테스트를 가지면 가능하다고 생각합니다.

단, 그 전에 한번 확인해 봤으면 하는 부분이 있습니다. 제가 판단했을 때 개발자가 모르는 상태에서 DB의 구조가 바뀐다는 것이 더 큰 이슈라고 생각합니다. DB의 구조가 변경되는 경우 개발자에게 공유되고 개발자에 의해 소스 코드가 변경된 후에 반영되는 것이 맞다고 봅니다. 만약 이 부분에 문제가 있다면 원론적인 문제를 해결할 수 있는지 찾아보면 좋겠어요.

만약 DBA 주도로 DB 구조가 바뀌는 상황이라 어쩔 수 없다면 junit과 같은 도구를 통해 테스트를 활용하는 수 밖에 없을 듯 합니다. 개인적으로는 근본적인 문제를 해결하는 방향으로 진행할 것을 추천합니다. 그래야 장애가 발생할 가능성도 적고, 효율성도 좋아진다고 봐요.

예를 들어 팀이 분리되어 있으며, json과 같은 API를 통해 서비스 간에 연동하는 경우에는 데이터 구조가 서로의 소통이 부족한 상태라면 내가 모르는 시점에 데이터 구조가 바뀔 수 있습니다. 이 때는 외부 API에 대한 단위 테스트를 만들어 반드시 확인해야 한다고 봅니다. 하지만 지금과 같은 상황에서는 개발자가 DB 구조의 변경을 인지하지 못한다는 것은 문제가 있다고 판단합니다.

단위테스트에 db를 포함시켜서 빌드가 성공한 시점의 스냅샷을 축적해나가는 게 필요하다고 생각합니다.

DBA입장에서는 문제가 발생하면 프로그램 오류라고 생각할 수 있기 때문에 아래와 같은 내장DB로 로직과 관련있는 데이터를 생성해서 단위테스트를 하고

나중에 말씀하신 것처럼 db의 변경으로 인해서 프로그램에 문제가 발생하면 문제가 발생하기 전에 테스트한 데이터를 가지고 다시 협의를 진행하면 좋겠습니다. H2 http://www.h2database.com/html/main.html hsqldb http://hsqldb.org/

두 개 중에서 맘에 드시는 걸로

의존성 추가하시고 DDL문파일 DML문 파일 2개를 만든 후에 DDL과 DML을 실행하는 EmbeddedDataBaseBuilder를 사용하기 위해 Spring-jdbc도 추가합니다.

이렇게 하시면 개발단계에서는 직접 대상 데이터베이스에 하시는 것보다 빠르게 하실 수 있어요

내장디비이기 때문에 프로그램 실행단계에서 초기화되어서 메모리에 적재되고

프로그램이 종료되면 다시 삭제됩니다.

사용은

  public DataSource dataSource(){
   
    return new EmbeddedDataBaseBuilder()
           .setName("slipDb")
           .setType(EmbeddedDataBaseType.HSQL)
           .addScript("mySchema.sql")
           .addScript("createData.sql")


           .build();   
}

일단 이렇게 테스트 단계에서 포함하고 배포 시에는 flyway를 이용해서

http://flywaydb.org/getstarted/how.html

데이터베이스에 SCHEMA_VERSION이란 테이블을 만든 후에

flyway의 규칙에 맞춰서 DDL파일을 생성하면

예를 들어 V1_Create_test_table.sql 하고

 V2_Create_test_table.sql 파일을 만들면 

버전 별로 변경된 내용이 기록됩니다.

RoR에서 db migration하는 것처럼 쓰실 수 있어요.