Creating a Multi Module Project[4]

Build 또는 Jib  x test 설정

 

 

 

🛠️ IntelliJ + Build 또는 Jib 빌드 시 -x test를 사용하는 이유: "내 로컬은 소중하니까!"

안녕하세요! 오늘은 스프링 부트 프로젝트를 Build 또는 Jib로 빌드하여 도커 이미지를 만들 때, 왜 우리가 인텔리제이 설정에서 -x test라는 마법의 옵션을 붙여야만 했는지 그 비하인드 스토리를 공유하려고 합니다. 😎

 

📋 배경: "내 PC엔 DB가 없는데?"

우리는 현대적인 개발을 지향합니다. 로컬 호스트 PC에 PostgreSQL이나 Kafka 같은 무거운 인프라를 직접 설치하지 않죠. 모든 것은 Docker Compose가 컨테이너 안에서 해결해 줄 테니까요! 🐳

하지만 여기서 문제가 발생합니다.

 

🛑 범인은 바로 인텔리제이와 Gradle의 결벽증!

이 챕터에서는 Build 태스크 수행 시 -x test 옵션 설정은 건너 뛰도록 하겠습니다

 

인텔리제이에서 Jib 빌드(jibDockerBuild)를 실행하면, 이 친구는 아주 정석(FM)대로 행동합니다.

1. 컴파일 시작 🏗️
2. 테스트 실행 (여기가 문제! ⚡)
3. 이미지 생성 및 푸시 🚢

스프링 부트 테스트 코드는 실행될 때 "어디 보자, DB 연결이 잘 되나?" 하고 체크를 시도합니다. 하지만 우리 로컬 PC엔 PostgreSQL이 없죠? 그럼 바로 Connection Refused 에러와 함께 빌드가 펑! 하고 터져버립니다. 💥

 

💡 해결사: -x test 옵션의 등장

이때 우리가 사용하는 옵션이 바로 -x test입니다. 이 옵션의 의미는 아주 명확합니다.

"Gradle아, 테스트는 건너뛰고(exclude) 바로 이미지나 구워줘!"

왜 이 방식이 더 '깔끔'할까요?

1. 환경의 완전한 격리 🛡️
   로컬 PC는 오직 '코드 작성'과 '빌드'만 담당합니다. DB가 없어도 빌드가 성공해야 한다는 우리만의 철학을 지킬 수 있습니다.
2. 압도적인 빌드 속도 ⚡
   매번 이미지를 만들 때마다 무거운 스프링 컨텍스트를 띄워 테스트를 돌릴 필요가 없습니다. 수정하고 바로 빌드해서 컨테이너로 띄워보는 사이클이 훨씬 빨라집니다.
3. 실전은 컨테이너에서! 🧪
   어설프게 로컬 호스트 환경에서 테스트하는 것보다, docker-compose up으로 실제 운영 환경과 똑같은 컨테이너 네트워크 안에서 API를 테스트하는 것이 훨씬 정확합니다.

🧐 STS4에서는 왜 잘 됐을까?

STS4(Eclipse)는 Gradle 태스크 간의 의존 관계를 인텔리제이보다 조금 더 느슨하게 잡거나, 사용자 설정을 더 관대하게 받아들이는 경향이 있습니다. 반면, 인텔리제이는 매우 꼼꼼한 친구라 정해진 순서를 다 지키려고 하죠. 그래서 인텔리제이로 넘어오면서 이 설정이 필수가 된 것입니다! 😅

 

✅ 결론

로컬 환경을 깨끗하게 유지하고, 도커 컨테이너 기반의 MSA 구조를 가져간다면 -x test는 선택이 아닌 필수입니다!

이제 인텔리제이 Run Configuration에 이 옵션을 똭! 박아두고, 스트레스 없는 빌드를 즐기세요! 🎉

 

github: https://github.com/nomadinsunda/elk_demo.git

GitHub - nomadinsunda/elk_demo