그 주의 화요일, 금요일을 지정 날짜로 업데이트 합니다
1. Flyway
Flyway란 데이터베이스의 형상관리 를 목적으로 하는 툴이다.
소스 코드를 git을 이용해서 관리한다면, Flyway 데이터베이스 소스코드를 관리한다.
git에서는 코드를 파일별로 로깅을 통해서 변화 이력을 추적한다면, Flyway는 데이터베이스의 DDL의 이력을 쌓아서 DDL이 어떻게 변화되었는지 관리하는 툴로 사용할 수 있다.
Flyway는 버전 관리 목적인 SCHEMA_VERSION 테이블을 통해 SQL 스크립트의 변화를 추적하면서 자동적으로 관리한다.
Flyway를 사용하는 이유는 배포 후 데이터 관리 및 유지 보수 중 스키마 구조가 바뀌는 상황 을 생각해 볼 수 있다.
만약 매번 배포 서버 DB에 직접 들어가서 테이블을 직접 수정하게 된다면 실수를 범할 수 있다.
이때, Flyway 를 사용하게 된다면 코드를 관리하는 것처럼 DB 변경 사항을 관리할 수 있다.
개발 도중 스키마가 변경되면 직접 배포 서버의 DB를 들어가 스키마를 변경하지 않고, 변경 사항을 코드로 관리할 수 있다.
(* 형상관리: 소프트웨어의 변경사항을 체계적으로 추적하고 통제하는 것)
2. Spring - @Profile, @ActiveProfiles
개발을 하다 보면 서로 다른 환경을 운영 해야 한다.
(ex. 로컬로 애플리케이션을 돌릴 때, 테스트를 돌릴 때, 실제 운영을 위한 배포를 할 때)
그렇기 때문에 각각의 환경들에 맞게 서로 다르게 빈 또는 프로퍼티들을 정의해야 할 수 있다.
- @Profile
@Profile는 해당 설정 클래스가 원하는 환경에서만 등록(활성화) 되도록 설정해주는 어노테이션이다.
만약 배포를 할 때에는 실제 실무에서 사용하는 DB에 연결하고, 테스트시에는 인메모리 DB를 사용하고 싶을 수 있다면, 이때 @Profile을 이용하게 된다.
-
@ActiveProfiles
@ActiveProfiles는 스프링 컨테이너를 실행할 때 현재의 실행 프로파일(환경)을 지정 하도록 도와주는 어노테이션이다.
만약 활성 프로파일이 test라면 test 프로파일이 아닌 다른 프로파일을 위해 등록된 빈들이나 설정 파일들은 모두 무시(비활성화) 될 것이다.@ActiveProfiles("test") public class Application { ・・・ }
배포 미션
실제로 배포를 하려다보면, JUnit을 활용한 test 단계와 local 환경에서 직접 애플리케이션을 확인할 때, 그리고 실제로 배포할 때 등 각 상황에 맞춰 설정을 다르게 적용할 필요성이 생긴다. 이에 따라 properties 설정 파일을 local, prod, test 등으로 나누어 다르게 설정 및 적용한다.
+)-Dspring.profiles.active=prod옵션을 통해application-prod.properties의 설정을 사용할 수 있다.$ java -jar -Dspring.profiles.active=prod [jar파일명]
3. JPA Dialect(방언)
ORM 의 가장 큰 특징중 하나는 객체 맵핑을 통해 자동으로 쿼리를 작성해주는 것이다. 하지만 DBMS인 Orcale,MySQL,MS-SQL 마다 쿼리가 조금씩 다르기 때문에, 이를 알릴 수 있도록 데이터베이스 유형을 지정 하도록 하는 것이 Dialect 설정이다.
JPA에서는 Dialect 라는 추상화된 방언 클래스를 제공하고 설정된 방언으로 각 DBMS에 맞는 구현체를 제공 한다.개발자는 JPA를 이용하게 되면 쿼리를 작성할 필요도 없고 JPA를 사용하더라도 원하는 Dialect만 설정해주면 DBMS 별로 조금씩 다른 SQL 방언을 걱정할 필요도 없어진다.
Dialect 설정은 따로 수동으로 지정해줄 수 도 있지만 Springboot 실행시 연결되어있는 데이터베이스에 알맞게 자동으로 지정이 되므로 필수적으로 지정할 필요는 없다. 또한 설정시 버전에 맞지 앟은 Dialect 설정을 하게 된다면 트랜잭션이 동작하지 않는 등의 오류가 생길 수 있으므로 주의해야한다.
ex) spring.jpa.properties.hibernate.dialect.MySQL55Dialect
4. 디미터 법칙(Law of Demeter)
디미터 법칙(Don’t Talk to Strangers) 의 핵심은 객체 구조의 경로를 따라 멀리 떨어져 있는 낯선 객체에 메시지를 보내는 설계는 피하라 는 것이다.
객체는 내부적으로 보유하고 있거나 메시지를 통해 확보한 정보만 가지고 의사 결정을 내려야 하고 다른 객체를 탐색해 뭔가를 일어나게 해서는 안 된다.
왜 낯선 객체에 메시지를 보내는 설계를 피해야 할까? ( 디미터 법칙을 위반했을 때의 문제점은 무엇일까? )
만약 그 객체에 변화가 생겼다면 (ex. 일급 컬렉션으로 리팩터링 등) 하나에 변화에 수많은 클래스들이 영향을 받고 객체 간 결합도가 높아짐으로써 변화에 유연히 대처하지 못하게 된다.
정리하자면,
디미터 법칙은 결합도와 관련된 법칙이고 객체라면 내부 구조를 숨겨야 하므로 디미터 법칙을 지켜야 한다.
객체의 내부 구조가 외부로 노출되는 경우 결합도에 문제가 된다.
ATDD 미션 과정 피드백
코드를 보면, getter가 줄줄이 이어지는 코드 형태 가 디미터 법칙을 위반한 전형적인 코드 형태이다.
이에 따라 ATDD 미션을 진행하면서 디미터 원칙을 위반했다는 피드백을 받았다.
✽ 이번 주 회고록
서비스 배포를 진행해보면서 배포에 관하여 좀 더 알아볼 수 있었던 한 주였다
이전에는 배포를 진행할때 설정 값을 다르게 주거나 파일 생성을 다르게 하여 구분하였다면,
이번에는 좀 더 구체적으로 환경에 따른 설정들을 어떻게 진행하는지를 학습할 수 있었다
또 도커를 통하여 진행하면서 도커의 편리함을 체험할 수 있었는데 아직 좀 더 학습해봐야 할 것 같다
[참조]
https://www.youtube.com/watch?v=pxDlj5jA9z4&t=110s
https://ecsimsw.tistory.com/entry/Flyway%EB%A1%9C-DB-Migration
https://mangkyu.tistory.com/178
https://bepoz-study-diary.tistory.com/371
https://goodgid.github.io/What-is-Dialect/
https://2dongdong.tistory.com/66
https://tecoble.techcourse.co.kr/post/2020-06-02-law-of-demeter/
