![[Spring Boot] 71. 스프링부트 블로그 v3 (RestAPI) (16) 빌드](https://image.inblog.dev?url=https%3A%2F%2Fsource.inblog.dev%2Ffeatured_image%2F2025-11-29T19%3A17%3A14.814Z-320e7960-4acc-4a22-a9c0-16c428d6cdb3&w=3840&q=75)
Contents
로그남기기통합테스트 목적
- 로컬 컴퓨터에서 돌아가는게 실제 서비스 환경에서도 잘 돌아가는지 확인하기 위해
- 코드를 수정하게 될 수 있는데 의존성 때문에 다른데 영향을 미칠 수 있음 → 근데 다시 실행해보면서 확인하기 번거롭기 때문에 테스트 코드로 확인 가능
application.properties를 여러개 나눈 이유
application-dev : 로컬 컴퓨터에서 개발자가 개발할 때 필요한 환경 - 가짜 데이터 가짜 환경
application-local : 최종 배포 전에 서버 환경과 똑같을 수는 없지만 구조 등 최대한 똑같이 맞추기 위해서 MySQL로 설정해두는 것. 환경(OS같은 것)은 똑같이 할 수 없지만 최대한 비슷하게 - 윈도우
application-prod : 진짜 환경이므로 local에서 통과해도 여기서 문제가 생길 수도 있긴 함. - 리눅스
→ 도커 : 윈도우 위에 리눅스를 만들 수 있음
로그를 남기는 이유
서비스할 때 문제 생기면 로그를 보고 고쳐야 하기 때문
sout → 로그에 레벨이 있고 레벨별로 해결해야 하므로 sout 사용X
info : 보관해뒀다가 특정한 일이 생겼을 때 꺼내 보는 것
gradle로 라이브러리 다운받고 관리 → 원래는 윈도우에 설치해야되지만 스프링은 내장되어있음
gradlew - 리눅스
gradle2.bat - 윈도우
git bash는 리눅스 하위 어쩌구라서 gradlew 로
= 빌드
내 소스코드도 .class로 컴파일
라이브러리는 어차피 .class로 제공됨
이미 되어있음 왜? 저장만 하면 .class로 컴파일 도 ㅣ어있음
내가 쓰고 있는 라이브러리들만 뽑아내서 (용량 줄이기)
안쓰는거 import 정리해야됨
⇒ 아무튼 실행될 때 필요한 파일들만 다 뽑아내서 패키징 → .jar라는 파일로 만듦
./gradlew clean build
→ ctrl+c 하면 서버 꺼짐
jar를 구워서 던져야 됨 → 서비스 환경에서 테스트 못함 → 테스트 코드를 실제 서비스 환경과 동일하게
1. 프로파일 설정 - 빌드(해당 프로파일로 테스트하고 jar가 생성됨)
2. 프로파일별 실행 (명령어)
3. 로그 레벨별 남기기
--------------------------
25.05.15 예정
4. CORS 설정 및 개념
5. Devops 세상
6. API 문서 만들기
로그남기기
로그에 레벨이 있음
exception 터질때 e 객체
e.printStackTrace → 에러 로그 중 가장 상세한 설명 (→ 너무 길고 불필요하지 하지 않나?)
에러의 핵심만 알면 나중에 디버깅할때 간단하게만 보고 싶지 않을까?
근데 상세한 설명이어야 해결 가능한 경우도 있긴 함
내가 잡아챈 에러는 아니까 e.getMessage만 해도 충분
근데 500 터지면(내가 모르는) 메세지만으로는 분석이 안될 수도 있음 → trace가 필요함
# log (trace -> debug -> info -> warn -> error) logging.level.shop.mtcoding.blog=INFO logging.level.org.hibernate.type=TRACE
trace라고 쓰면 trace -> debug -> info -> warn -> error 전부 볼 수 있음
debug라고 쓰면 debug -> info -> warn -> error 볼 수 있음
error=치명적인거
warn = 나중에 고쳐야하는 언젠간 문제가 생길지도
info = 정상적 (언제 누가 로그인을 했고 어디까지 읽었으며 이런걸 기록
sout인데 레벨만 다르게 있다고 생각하면 됨(?
(서버 실행시 spring.jpa.open-in-view warn → dto가 아니라 모델을 넘기면 뷰 렌더링중에 lazy 로딩에 의해 db 쿼리가 발생할 수 있다는 경고 - 끄면 service까지만 되고 controller에서는 X - 뷰에서 lazy 로딩에 의해 터지는 일X)
application-prod.properties
application-dev : 개발(h2) → build (test, jar 생성)
test할때 deb profile을 땡겨씀 → application에서
spring.profiles.active=dev 라고 설정해뒀기 때문만들어진 jar는 dev든 local이든 똑같으므로 실행할때 prod (=다른 profile 땡겨 쓸 수 있음)
application-prod : 실제 서비스 실제 db로 연결
application-local : 실제 서비스 로컬 db로 연결
집중력 다뒤짐 와
테스트는 dev로 하면 됨
근데 application에서 active를 local로 바꾸면 테스트 다 터짐
→ db가 없어서 터짐
jar 파일이 만들어지고 실행될 때는 properties 중에서 하나 선택해서 실행할 수 있음
jar 파일이 만들어지는 거지 실행이 되는게 아님 테스트할때 어떤 모드로 테스트할지는 application.properties가 결정
jar를 그냥 실행할거면 dev로 하고
통합테스트 코드 다 만들고 나서
profile 설정해야됨
그다음 빌드 해봐야됨 잘 되는지
로컬에서 잘 되는지 확인해보고 던져야 되니까
잘 되니까 로컬에서 실제 db도 연결해봐야 됨
다 확인 되면 배포
파일을 고치면서X 파일을 만들어두고 하는게 편하다 → application-local 같은 파일 만드는 것
data.sql이 실행되고 테스트 실행되면 됨
뭐 세팅하라고여..?
목적지 jar
그니까 local에서도 똑같이 해봐야 됨 서버 환경에서는 툴로 실행하는게 아니니까!
build해서 jar로 실행해봐야됨
근데 local은 테스트 파일 실행 안되므로 test 없이 jar 파일을 구워보자
./gradlew clean build -x test
blog-1.0.jar 가 있는 폴더에서 git bash로
java -jar blog-1.0.jar jar 파일이 구워지는건 무슨 설정이든 똑같음
테스트를 하고 안하고의 차이
실행을 local로 하도록 application에 설정되어있지만 다른걸로 변경해서 실행가능하다.
특정 모드로 실행시키는 방법
java -jar blog-1.0.jar --spring.profiles.active=dev
=> dev 모드로 실행돼서 더미가 있음
-> 테스트 환경만 바꿔보는 것
-> 실제 서비스 환경에서는 dev가 아닌 prod로 하겠지
local로 실행
⇒ 그냥 실행하지 말고 무조건 지정해서 실행하도록 하기
dev - h2
local - mysql
mysql → 테스트 코드+더미 없음 : local에서 더미데이터 실행되게 설정 가능 → 근데 테스트가 끝났을때 영구적으로지워주는 세팅 필요
최소 local에서는 잘돌아가는지 확인하고 던져야됨 리눅스 존잘이어야 거기서 수정 가능함 그니까 로컬에서 확인 잘 하고 테스트 다 해봐야 귀찮아서 안하는거 안됨 학생때는 ㄱㅊ지만 실제로 들어가면 개발 완료 = 테스트까지 다 돼서 잘 돌아가는 것 → 귀찮아서 생략햇다가 위약금 물고 어쩌구
로그 남기기
bad_request - warning 정도니까
info도 남겨야
→ filter에서 남겨야 본 코드에 영향을 안미치고 필터 들어오고 나갈때 남김
근데 지금은 콘솔에 남고 나중에는 파일에 남겨야됨 (dbX)
json db에
수집 목적이라서 수정/삭제/일관성 등 중요하지 않으므로 정규화 되지 않은 noSQL을 사용해서
라이브러리 돈주고 쓰는 aws cloud watch / sentry io 것 같은거
sout과 똑같은데 레벨 지정이 가능해서 debug에 적고 막 나중에 주석처리 안해도 됨
log.debug(reqDTO.toString()); 이런식으로 하면 ㄴ중에 주석처리 안해도 됨
jar로 던질때 upload 폴더 안들어감
따로 던져줘야..?
Share article