일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
- SQL
- 리눅스
- spring
- oracle
- 파이썬 소스
- hyperledger
- 프로젝트
- 학점
- 운영체제
- dynamic query
- gradle
- MongoDB
- 자바 프로젝트
- K6
- 파이썬
- JVM
- 알고리즘
- c#
- 유사코드
- 문법 정리
- 초대장
- auto configure
- resilience4j
- 백준 알고리즘
- jsp
- 자바
- smart cast
- 오라클
- 오라클 디비
- 티스토리
- Today
- Total
모종닷컴
Gradle에 대해 알아보자. 본문
멀티 모듈 프로젝트를 구성하다보니 그레이들에 대해 참 모르고 있던 부분들이 많았다는 걸 깨닳았네요.. Gradle 관련 공부를 어떤 방식으로 진행할 지 아직 정하지 못했기 때문에 간단하게 공식 문서상에서 소개하는 Gradle에 대해 알아보도록 하겠습니다.
Gradle 이란?
Gradle은 거의 모든 유형의 소프트웨어를 빌드 할 수 있음 만큼 충분히 유연하게 설계된 오픈 소스 빌드 자동화 도구입니다.
Gradle 주요 특징
- 고성능 : Gradle은 입력 또는 산출물이 변경되어 실행해야 하는 작업만 실행함으로써 불필요한 작업을 방지합니다. 또한 빌드 캐시를 사용하여 이전 실행 또는 공유 빌드 캐시가 있는 다른 시스템에서도 작업 산출물을 재사용할 수 있습니다. 또한 현재까지도 팀에서 Gradle의 성능을 개선하기 위해 지속적으로 노력하고 있다.
- JVM 기반 : Gradle은 JVM에서 실행되며 이를 사용하려면 JDK가 설치되어 있어야 합니다. 이것은 사용자 정의 작업 유형 및 플러그인과 같은 빌드 로직에서 표준 Java API를 사용할 수 있으므로 Java 플랫폼에 익숙한 사용자에게는 보너스입니다. 이 특징으로 인해 다른 플랫폼에서도 Gradle은 쉽게 실행할 수 있습니다.
- Conventions : Gradle은 Maven의 책에서 일부를 가져와서 규칙을 구현하여 Java 프로젝트와 같은 일반적인 유형의 프로젝트를 쉽게 구축할 수 있도록 되어있습니다. 적절한 플러그인을 적용하면 많은 프로젝트에서 슬림한 빌드 스크립트로 쉽게 끝낼 수 있습니다. 그러나 이러한 규칙이 제한되어 있지는 않습니다. Gradle을 사용하면 규칙을 재정의하고, 고유 작업을 추가하고, 규칙 기반 빌드에 다른 많은 사용자 지정을 수행할 수 있습니다.
- 확장성 : Gradle을 쉽게 확장하여 고유한 작업 유형을 제공하거나 모델을 빌드할 수 있습니다.
- IDE 지원 : Intellij IDEA, Eclips 등 주요 IDE를 사용하여 Gradle 빌드를 가져와 상호 작용할 수 있습니다.
- Insight : Build Scan은 빌드 문제를 식별하는 데 사용할 수 있는 빌드 실행에 대한 광범위한 정보를 제공합니다. 빌드 성능과 관련된 문제를 식별하는 데 특히 유용합니다. 빌드 스캔을 다른 사람과 공유할 수도 있습니다.
Gradle에 대해 알아야 할 5가지
Gradle은 유연하고 강력한 빌드 도구로서 처음 시작할 때 쉽게 겁먹을 수 있습니다. 그러나 다음 핵심 원칙을 이해하면 Gradle이 훨씬 더 접근하기 쉬워지고 도구를 알기도 전에 도구에 익숙해질 것입니다.
1. 범용 빌드 도구
Gradle을 사용하면 빌드하려는 대상이나 수행 방법에 대해 거의 가정하지 않기 때문에 모든 소프트웨어를 빌드할 수 있습니다. 가장 주목할만한 제한은 종속성 관리가 현재 Maven 및 Ivy 호환 리포지토리와 파일 시스템만 지원한다는 것입니다.
이것은 빌드를 만들기 위해 많은 작업을 수행해야 한다는 의미는 아닙니다. Gradle을 사용하면 플러그인을 통해 규칙 및 미리 빌드된 기능 계층을 추가하여 일반적인 유형의 프로젝트를 쉽게 빌드할 수 있습니다. 사용자 지정 플러그인을 만들고 게시하여 고유한 규칙을 캡슐화하고 기능을 빌드할 수도 있습니다.
2. 테스크를 기반한 핵심 모델
Gradle은 빌드를 테스크(작업 단위)의 방향성 비순환 그래프(DAG)로 모델링합니다. 이것이 의미하는 바는 빌드가 기본적으로 테스크 세트를 구성하고 종속성에 따라 함께 연결하여 해당 DAG을 생성한다는 것입니다. 작업 그래프가 생성되면 Gradle은 어떤 작업을 어떤 순서로 실행해야 하는지 결정한 다음 실행을 진행합니다.
이 다이어그램은 작업 간의 종속성을 화살표로 나타낸 두 가지 예제 작업 그래프를 보여줍니다.
거의 모든 빌드 프로세스를 이러한 방식으로 작업(task) 그래프로 모델링할 수 있으며, 이것이 Gradle이 매우 유연한 이유 중 하나입니다. 그리고 해당 작업 그래프는 작업 종속성 메커니즘을 통해 연결된 작업과 함께 플러그인과 자체 빌드 스크립트로 정의할 수 있습니다.
작업(task)는 다음으로 구성됩니다.
- Actions : 파일 복사 또는 소스 컴파일과 같은 작업을 수행하는 부분
- Inputs : Actions이 사용하거나 작동하는 값, 파일, 디렉토리
- Outputs : Actions이 수정하거나 생성하는 파일, 디렉토리
사실 위의 모든 내용은 작업이 무엇을 해야 하는지에 따라 선택 사항입니다. 표준 수명 주기 작업과 같은 일부 작업에는 Actions이 없습니다. 그들은 단순히 편의상 여러 작업을 함께 집계합니다.
마지막으로, Gradle의 증분 빌드 지원은 강력하고 안정적이므로 clean을 수행하지 않는다면 빌드를 빠르게 실행하도록 유지합니다.
3. Gradle의 고정 빌드 단계
Gradle은 세 단계로 빌드 스크립트를 해석하고 실행한다는 것을 이해하는 것은 중요합니다.
공식 문서에 evaluation이라고 되어있는데 단어 원래 뜻대로 평가라고 해석하면 좀 이상해서 의미를 조금 유추해 '해석'한다 정도로 추측했습니다.
- 초기화 : 빌드를 위한 환경을 설정하고 참여할 프로젝트를 결정합니다
- 구성 : 빌드에 대한 작업 그래프를 구성 및 구성한 다음 사용자가 실행하려는 작업을 기반으로 실행해야 하는 작업과 순서를 결정합니다.
- 실행 : 구성 단계가 끝날 때 선택한 작업을 실행합니다
이러한 단계는 Gradle의 빌드 라이프사이클을 형성합니다.
잘 설계된 빌드 스크립트는 대부분 명령적 논리보다는 선언적 구성으로 구성됩니다. 이런 구성은 2.구성 단계에서 이해할 수 있게 해석됩니다. 몇몇은 3.실행 단계에서 해석되는 작업 Action(doLast{}, doFirst{} 등)도 있습니다. 2.구성 단계에서 해석된 코드는 3.실행 단계에서 발생하는 변경 사항을 보지 못하기 때문에 이것은 중요합니다.
2.구성 단계의 또 다른 중요한 측면은 빌드가 실행될 때마다 관련된 모든 것이 해석된다는 것입니다. 그렇기 대문에 구성 단계에서 비용이 많은 드는 작업을 피하는 것이 가장 좋습니다. 빌드 스캔은 무엇보다도 이러한 핫스팟을 식별하는 데 도움이 될 수 있습니다.
4. 여러 가지 방법으로 확장
Gradle과 함께 번들된 빌드 로직으로만 사용하여 프로젝트를 빌드할 수 있다면 좋겠지만 거의 불가능합니다. 대부분의 빌드에는 커스텀 빌드 논리를 추가해야 하는 몇 가지 특별한 요구 사항이 있습니다.
Gradle은 다음과 같이 확장할 수 있는 몇 가지 메커니즘을 제공합니다.
- 사용자 정의 작업 타입 : 빌드에서 기존 테스크가 수행할 수 없는 일부 작업을 수행하려는 경우 직접 테스크 유형을 작성할 수 있습니다. 일반적으로 사용자 지정 작업 유형의 소스 파일을 buildSrc 디렉토리 또는 패키지 플러그인에 저장하는 것이 가장 좋습니다. 그런 다음 Gradle에서 제공하는 테스크 유형처럼 사용자 정의 테스크 유형을 사용할 수 있습니다.
- 사용자 정의 작업 actions : Task.doFirst() 및Task.doLast() 메서드를 통해 작업 전후에 실행되는 사용자 지정 빌드 논리를 연결할 수 있습니다.
- 프로젝트 및 작업에 대한 추가 속성 : 이 메커니즘을 이용하면 프로젝트나 테스크에 고유한 속성을 추가한 다음 고유한 사용자 지정 작업 또는 기타 빌드 로직에서 사용할 수 있습니다. 추가 속성은 Gradle의 핵심 플러그인에서 생성한 것과 같이 명시적으로 생성하지 않은 작업에도 적용할 수 있습니다.
- 사용자 정의 컨벤션 : 컨벤션은 사용자가 더 쉽게 이해하고 사용할 수 있도록 빌드를 단순화하는 강력한 방법입니다. 이것은 Java builds 와 같은 표준 프로젝트 구조 및 명명 컨벤션을 사용하는 빌드에서 볼 수 있습니다 . 컨벤션을 제공하는 자체 플러그인을 작성할 수 있습니다. 빌드의 관련 측면에 대한 기본값을 구성하기만 하면 됩니다.
- 사용자 정의 모델 : Gradle을 사용하면 작업, 파일 및 종속성 구성을 넘어 빌드에 새로운 개념을 도입할 수 있습니다. 빌드에 source set 개념을 추가하는 대부분의 언어 플러그인에서 이를 확인할 수 있습니다. 빌드 프로세스의 적절한 모델링은 빌드의 사용 편의성과 효율성을 크게 향상시킬 수 있습니다.
5. API에 대해 작동하는 빌드 스크립트
Gradle의 빌드 스크립트를 실행 가능한 코드로 보는 것은 쉽습니다. 그러나 이는 구현 세부 사항입니다. 잘 설계된 빌드 스크립트는 소프트웨어를 빌드하는 데 필요한 단계를 설명하는 것이지, 이러한 단계가 어떻게 작동해야 하는지를 설명하는 것이 아닙니다. 이 작업은 사용자 지정 작업 유형 및 플러그인을 위한 작업입니다.
Gradle의 기능과 유연성은 빌드 스크립트가 코드라는 사실에서 비롯된다는 일반적인 오해가 있습니다. 힘을 제공하는 것은 기본 모델과 API입니다.
그러나 빌드 스크립트를 실행 가능한 코드로 보는 것이 유용한 한 가지 영역이 있습니다. 빌드 스크립트의 구문이 Gradle의 API에 매핑되는 방식을 이해하는 것입니다 Groovy DSL Reference 와 Javadocs 로 구성된 API 문서 는 메서드와 속성을 나열하고 클로저와 작업을 언급합니다. 빌드 스크립트의 컨텍스트 내에서 이러한 것들이 무엇을 의미할까요? API 문서를 효과적으로 사용할 수 있도록 Groovy Build Script Primer 를 확인 하여 해당 질문에 대한 답을 알아볼 수 있습니다.
원문
https://docs.gradle.org/current/userguide/what_is_gradle.html
'Programming > Gradle' 카테고리의 다른 글
[Gradle] 특정 환경에 테스트 필터 적용하기 (0) | 2023.05.01 |
---|---|
Gradle Custom Task, Plugin with buildSrc (0) | 2023.03.11 |
Gradle - 빌드 스크립트 작성 기초 (0) | 2022.09.17 |
Gradle 디렉토리 (0) | 2022.09.04 |
Gradle의 빌드 라이프사이클 (0) | 2022.08.28 |