[SpringBoot] Gradle

임유빈·2022년 8월 1일
0

SpringBoot

목록 보기
2/10
post-thumbnail

1. Gradle

2012년에 출시된 groovy 기반으로 한 오픈소스 빌드도구로, 거의 모든 타입의 소프트웨어 (어떤 언어든 상관없이 빌드하겠다)를 빌드할 수 있는 빌드 자동화 시스템이다.
프로젝트를 실행 가능한 어플리케이션으로 만들어주는 툴

2. 빌드

소스코드를 컴파일 테스트 , 정적분석 등을 실행하여 실행 가능한 애플리케이션으로 만들어주는 과정이다.

3. 다양한 라이브러리

  • 스프링부트 라이브러리 : 실제 동작하는 라이브러리
    • spring-boot-starter-web
      • spring-boot-starter-tomcat: 톰캣(웹서버)
    • spring-boot-starter-thymeleaf: 타임리프 템플릿 엔진(View)
    • spring-boot-starter(공통): 스프링부트 + 스프링 코어 + 로깅
      • spring-boot
        • spring-dore
      • spring-boot-starter-logging
        • logback,slf4j
  • 테스트 라이브러리 : 테스트 할 때 사용하는 라이브러리
    • spring-boot-starter-test
      • junit: 테스트 프레임워크 : 자바테스트를 유닛 기반으로 테스트하는 도구
      • mockito: 목 라이브러리
      • assertj: 테스트 코드를 좀 더 편하게 작성하게 도와주는 라이브러리
      • spring-test: 스프링 통합 테스트 지원
  • 문제점
    • 라이브러리를 다운로드 및 추가하는 번거로움
    • 개발자들 간의 버전관리 어려움
    • 다운받은 jar 파일의 보안 위험 :
      • jpa는 테이블구조에서 객체로 바꿔서 관리해주는 라이브러리이다.
      • orm은 객체와 관계형 데이터베이스의 데이터를 자동으로 매핑 (연결)해주는 도구이다.

4. 빌드 도구

위의 문제점들을 한번에 해결해주는 도구로 계속해서 늘어나는 라이브러리 자동추가 및 관리를 해주며, 프로젝트를 진행하며 라이브러리의 버전을 쉽게 동기화를 해준다.

5. groovy : jvm 상에서 실행되는 스크립트언어이다.

6. Gradle

(1) 프로젝트를 설정 주입 방식으로 정의

  • maven의 상속구조보다 재사용에 용이하고, 프로젝트의 조건을 체크할 수 있어서 프로젝트별로 주입되는 설정을 다르게 할 수 있다.

  • 원래는 프로젝트를 맞춰서 모듈을 만든다면, 설정 주입 방식은 모듈을 만들고 프로젝트에 주입한다.

(2) 멀티 프로젝트 빌드

하나의 레파토리지 내에 여러개의 하위 프로젝트를 구성하는 것으로, 보통 프로젝트는 하나이나 멀티 프로젝트 빌드는 레파지토리 하나를 만들고 프로젝트 네 개를 다 관리해준다 : 빌드 속도가 빠르다.

  • 예시 : 관리자 서버와 사용자 서버를 분리해서 진행해야 될 경우 하나의 모듈로 하면 많은 코드를 복붙해서 구현해야 하지만, gradel을 사용하면 중복을 피할 수 있다.

(3) Gradle 빌드 속도가 빠른 이유

  • 점진적 빌드 : gradle은 빌드 실행 중 마지막 빌드 호출 이후에 task의 입력, 출력 혹은 구현이 변경됐는지 확인을 하며, 최신 상태로 간주하지 않는다면 빌드는 실행되지 않는다.
    • 빌드가 1부터 10까지 한번에 가는게 아닌 1 빌드, 2빌드, 3빌드 이런 구조이다.
    • 한번에 빌드하면 속도가 오래 걸린다 > 조각조각 빌드하면 빨라진다 : 도로 전체공사하면 오래 걸린다 > 도로를 좁은길로 공사하면 지나다닐 수는 있다

  • 빌드 캐시 : 두 개 이상의 빌드가 돌아가고, 하나의 빌드에서 사용되는 파일들이 다른 빌드들에 사용된다면 gradle은 빌드 캐시를 이용해 이전 빌드의 결과물을 다른 빌드에서 사용할 수 있다.

  • 데몬 프로세스 : 서비스의 요청에 응답하기 위해 오래동안 살아있는 프로세스로 그레이들의 데몬 프로세스는 메모리 상에 빌드 결과물을 보관한다 (이로 인해 한번 빌드된 프로젝트는 다음 빌드에서 매우 적은 시간만 소요된다)

(4) 사용방법

  • api : 내부 의존성을 컴파일과 런타임 모두에 보이는 API 의존성

  • implementation : 내부 의존성을 런타임에서만 보이는 구현 의존성, 코드와 직접적으로 연관이있는 라이브러리이다.

  • compileOnly : 컴파일에만 사용되는 의존성 정의 > 실제 구동되는 프로그램으로 만들때만 사용한다.

  • runtimeOnly : 런타임에만 사용되는 의존성 정의 > 프로그램이 진짜 구동될 때 시작될 때만 사용되는 라이브러리이다.

(5) 의존성

의존성이란 B객체가 A객체를 사용하는 것을 의미한다. 해당 이미지에서 화살표가 나가는 쪽이 의존하고 있는 것인데 여기서 내부라는 것이 붙은 것은 B가 A를 의존, 즉 B가 A를 라이브러리로 사용한다고 했을 때 이것을 C가 볼 수 있는지의 여부라고 보면 된다. API는 이런 의존성을 컴파일과 런타임 모두에 보이게 되고 implementation는 컴파일시에는 보이지 않게 된다.

이러한 implementation 경우에는 의존성을 최소화하였기 때문에 빌드 속도에도 도움이 된다. API는 A가 수정되었을 시 B까지 해당 내용을 알고 있기 때문에 B 뿐만 아니라 C까지 모두 영향을 끼친다. implementation 같은 경우 내부 의존성이 컴파일 타임에 진행되지 않으므로 B까지만 영향을 끼치기 때문이다.

이것들을 해결하기 위해 런타임때 쓰는 라이브러리 컴파일 때 쓰는 라이브러리를 구분해서 만든 것이다.

0개의 댓글