[번역] Gradle 공식문서 - Introduction

Ref. Gradle v.7.4.1
📌 이 글에서는 공식문서의 Introduction 부분만 다룹니다.

Overview

Gradle은 거의 모든 유형의 소프트웨어를 빌드할 수 있을 만큼 충분히 유연하도록 설계된 오픈 소스 빌드 자동화 도구입니다. 다음은 가장 중요한 기능 중 일부에 대한 개괄적인 개요입니다.

• High Performance(고성능)

  Gradle은 입력 또는 출력이 변경되어 실행해야 하는 작업만 실행하여 불필요한 작업을 방지합니다. 또한 빌드 캐시를 사용하여 이전 실행 또는 다른 시스템(공유 빌드 캐시 포함)의 작업 출력을 재사용할 수 있습니다.

  Gradle이 구현하는 다른 많은 최적화가 있으며 개발 팀은 Gradle의 성능을 개선하기 위해 지속적으로 노력하고 있습니다.

• JVM foundation(JVM 기초)

  Gradle은 JVM에서 실행되며 이를 사용하려면 JDK(Java Development Kit)가 설치되어 있어야 합니다. 이것은 사용자 정의 작업 유형 및 플러그인과 같은 빌드 로직에서 표준 Java API를 사용할 수 있으므로 Java 플랫폼에 익숙한 사용자를 위한 보너스입니다. 또한 다양한 플랫폼에서 Gradle을 쉽게 실행할 수 있습니다.

  Gradle은 JVM 프로젝트 빌드에만 국한되지 않으며 기본 프로젝트 빌드 지원과 함께 패키지로 제공됩니다.

• Conventions(규약)

  Gradle은 Maven의 책에서 일부를 가져와서 규칙을 구현하여 Java 프로젝트와 같은 일반적인 유형의 프로젝트를 쉽게 구축할 수 있도록 합니다. 적절한 플러그인을 적용하면 많은 프로젝트를 위한 슬림한 빌드 스크립트로 쉽게 끝낼 수 있습니다. 그러나 이러한 규칙이 당신을 제한하지 않습니다. Gradle을 사용하면 규칙을 재정의하고, 고유한 작업을 추가하고, 규칙 기반 빌드에 다른 많은 사용자 정의를 만들 수 있습니다.

• Extensibility(확장성)

  Gradle을 쉽게 확장하여 고유한 작업 유형을 제공하거나 모델을 빌드할 수도 있습니다. 이에 대한 예는 Android 빌드 지원을 참조하세요. 여기에는 flavors 및 build types과 같은 많은 새로운 빌드 개념이 추가됩니다.

• IDE support(IDE 지원)

  Android Studio, IntelliJ IDEA, Eclipse 및 NetBeans와 같은 여러 주요 IDE를 사용하여 Gradle 빌드를 가져와 상호 작용할 수 있습니다. Gradle은 또한 프로젝트를 Visual Studio로 로드하는 데 필요한 솔루션 파일 생성을 지원합니다.

• Insight(인사이트)

  Build Scans는 빌드 문제를 식별하는 데 사용할 수 있는 빌드 실행에 대한 광범위한 정보를 제공합니다. 빌드 성능과 관련된 문제를 식별하는 데 특히 유용합니다. Build Scans를 다른 사람과 공유할 수도 있습니다. 이는 빌드 문제를 해결하기 위해 조언을 구해야 할 때 특히 유용합니다.

Five things you need to know about Gradle

Gradle은 유연하고 강력한 빌드 도구입니다. 다음의 핵심 원칙을 이해하면 Gradle을 훨씬 더 쉽게 접근할 수 있고 사용자가 알기도 전에 도구에 익숙해질 것입니다.

1. Gradle is a general-purpose build tool(Gradle은 범용 빌드 도구입니다.)

Gradle을 사용하면 빌드하려는 대상이나 수행 방법에 대한 가정이 거의 없기 때문에 모든 소프트웨어를 빌드할 수 있습니다. 가장 주목할만한 제한은 종속성 관리가 현재 Maven 및 Ivy 호환 리포지토리와 파일 시스템만 지원한다는 것입니다.

이것은 빌드를 만들기 위해 많은 작업을 수행해야 한다는 의미는 아닙니다. Gradle을 사용하면 플러그인을 통해 규칙 및 미리 빌드된 기능 계층을 추가하여 일반적인 유형의 프로젝트(예: Java 라이브러리)를 쉽게 구축할 수 있습니다. 사용자 지정 플러그인을 만들고 게시하여 고유한 규칙을 캡슐화하고 기능을 빌드할 수도 있습니다.

2. The core model is based on tasks(핵심 모델은 tasks를 기반으로 합니다.)

Gradle은 빌드를 tasks(work 단위)의 방향성 비순환 그래프(DAG)로 모델링합니다. 이것이 의미하는 바는 빌드가 기본적으로 tasks 세트를 구성하고 종속성에 따라 함께 연결하여 해당 DAG를 생성한다는 것입니다. task 그래프가 생성되면 Gradle은 어떤 task를 어떤 순서로 실행해야 하는지 결정한 다음 실행을 진행합니다.

이 다이어그램은 task 간의 종속성이 화살표로 표시된 두 가지 예시 작업 그래프(하나는 추상적이고 다른 하나는 구체적)를 보여줍니다.

거의 모든 빌드 프로세스를 이러한 방식으로 작업 그래프로 모델링할 수 있으며, 이것이 Gradle이 매우 유연한 이유 중 하나입니다. 그리고 해당 작업 그래프는 작업 종속성 메커니즘을 통해 함께 연결된 작업과 함께 플러그인과 자체 빌드 스크립트로 정의할 수 있습니다.

task 자체는 다음으로 구성됩니다.

• Actions: 파일 복사 또는 소스 컴파일과 같은 작업을 수행하는 부분
• Inputs: 작업이 사용하거나 작동하는 값, 파일 및 디렉터리
• Outputs: 작업이 수정하거나 생성하는 파일 및 디렉터리

사실 위의 모든 것은 task가 수행해야 하는 작업에 따라 선택 사항입니다. 표준 수명 주기 작업과 같은 일부 작업에는 action이 없습니다. 그들은 단순히 편의상 여러 작업을 함께 집계합니다.

Gradle의 incremental build 지원은 강력하고 안정적이므로 실제로 정리를 수행하지 않으려는 경우 정리 작업을 피하여 빌드를 빠르게 실행하도록 유지합니다.

3. Gradle has several fixed build phases(Gradle에는 몇 가지 고정 빌드 단계가 있습니다.)

Gradle이 빌드 스크립트를 세 단계로 평가하고 실행한다는 것을 이해하는 것이 중요합니다.

1. Initialization(초기화)
   빌드를 위한 환경을 설정하고 참여할 프로젝트를 결정합니다.

2. Configuration(구성)
   빌드에 대한 작업 그래프를 생성 및 구성한 다음 사용자가 실행하려는 작업을 기반으로 실행해야 하는 작업과 순서를 결정합니다.

3. Execution(실행)
   구성 단계의 끝에서 선택한 작업을 실행합니다.

이러한 단계는 Gradle의 빌드 수명 주기를 형성합니다.

잘 설계된 빌드 스크립트는 대부분 명령적 논리보다는 선언적 구성으로 구성됩니다. 해당 구성은 구성 단계에서 당연히 평가됩니다. 그럼에도 불구하고 이러한 많은 빌드에는 실행 단계 중에 평가되는 task actions(예: doLast {} 및 doFirst {} 블록을 통한 작업)도 있습니다. 이는 구성 단계에서 평가된 코드가 실행 단계에서 발생하는 변경 사항을 볼 수 없기 때문에 중요합니다.

구성 단계의 또 다른 중요한 측면은 빌드가 실행될 때마다 관련된 모든 것이 평가된다는 것입니다. 그렇기 때문에 구성 단계에서 비용이 많이 드는 작업을 피하는 것이 가장 좋습니다. Build Scans는 무엇보다도 이러한 핫스팟을 식별하는 데 도움이 될 수 있습니다.

4. Gradle is extensible in more ways than one(Gradle은 여러 가지 방법으로 확장 가능합니다.)

Gradle과 함께 번들로 제공되는 빌드 로직만 사용하여 프로젝트를 빌드할 수 있다면 좋겠지만 거의 불가능합니다. 대부분의 빌드에는 사용자 지정 빌드 논리를 추가해야 하는 몇 가지 특별한 요구 사항이 있습니다.

Gradle은 다음과 같이 확장할 수 있는 몇 가지 메커니즘을 제공합니다.

• Custom task types(사용자 정의 작업 유형).

  빌드가 기존 작업이 할 수 없는 일부 작업을 수행하도록 하려면 고유한 작업 유형을 작성하기만 하면 됩니다. 일반적으로 사용자 정의 작업 유형에 대한 소스 파일을 buildSrc 디렉토리 또는 패키지된 플러그인에 넣는 것이 가장 좋습니다. 그런 다음 Gradle에서 제공하는 것과 마찬가지로 사용자 지정 작업 유형을 사용할 수 있습니다.

• Custom task actions(사용자 정의 작업 액션).

  Task.doFirst() 및 Task.doLast() 메서드를 통해 작업 전후에 실행되는 사용자 지정 빌드 논리를 연결할 수 있습니다.

• Extra properties on projects and tasks(프로젝트 및 작업에 대한 추가 속성).

  이를 통해 프로젝트 또는 작업에 고유한 속성을 추가한 다음 고유한 사용자 지정 작업 또는 기타 빌드 논리에서 사용할 수 있습니다. 추가 속성은 Gradle의 핵심 플러그인에서 생성한 것과 같이 명시적으로 생성하지 않은 작업에도 적용할 수 있습니다.

• Custom conventions(사용자 정의 규칙).

  규칙은 사용자가 더 쉽게 이해하고 사용할 수 있도록 빌드를 단순화하는 강력한 방법입니다. 이것은 Java 빌드와 같은 표준 프로젝트 구조 및 명명 규칙을 사용하는 빌드에서 볼 수 있습니다. 규칙을 제공하는 자체 플러그인을 작성할 수 있습니다. 빌드의 관련 측면에 대한 기본값을 구성하기만 하면 됩니다.

• A custom model(사용자 정의 모델).

  Gradle을 사용하면 작업, 파일 및 종속성 구성을 넘어 새로운 개념을 빌드에 도입할 수 있습니다. 소스 세트의 개념을 빌드에 추가하는 대부분의 언어 플러그인에서 이를 확인할 수 있습니다. 빌드 프로세스의 적절한 모델링은 빌드의 사용 용이성과 효율성을 크게 향상시킬 수 있습니다.

5. Build scripts operate against an API(API에 대해 작동하는 빌드 스크립트)

Gradle의 빌드 스크립트를 실행 가능한 코드로 보는 것은 쉽습니다. 그러나 그것은 구현 세부 사항입니다. 잘 설계된 빌드 스크립트는 해당 단계가 작업을 수행하는 방법이 아니라 소프트웨어를 빌드하는 데 필요한 단계를 설명합니다. 사용자 정의 작업 유형 및 플러그인을 위한 작업입니다.

그러나 빌드 스크립트를 실행 가능한 코드로 보는 것이 유용한 한 가지 영역이 있습니다. 빌드 스크립트의 구문이 Gradle의 API에 매핑되는 방식을 이해하는 것입니다. Groovy DSL Reference와 Javadocs로 구성된 API 문서는 메서드와 속성을 나열하고 클로저와 작업을 참조합니다. 빌드 스크립트 컨텍스트 내에서 이것이 의미하는 바는 무엇입니까? API 문서를 효과적으로 사용할 수 있도록 Groovy Build Script Primer를 확인하여 해당 질문에 대한 답을 알아보세요.