이 페이지에서는 작업 기반 빌드 시스템, 작동 방식, 작업 기반 시스템에서 발생할 수 있는 몇 가지 문제에 대해 설명합니다. 셸 스크립트 이후 작업 기반 빌드 시스템은 빌드의 다음 논리적 진화입니다.
작업 기반 빌드 시스템 이해
태스크 기반 빌드 시스템에서 기본 작업 단위는 태스크입니다. 각 작업은 모든 종류의 논리를 실행할 수 있는 스크립트이며, 작업은 자신보다 먼저 실행되어야 하는 다른 작업을 종속 항목으로 지정합니다. 오늘날 사용되는 대부분의 주요 빌드 시스템(예: Ant, Maven, Gradle, Grunt, Rake)은 작업 기반입니다. 최신 빌드 시스템에서는 셸 스크립트 대신 엔지니어가 빌드를 실행하는 방법을 설명하는 빌드 파일을 만들어야 합니다.
Ant 매뉴얼의 다음 예를 참고하세요.
<project name="MyProject" default="dist" basedir=".">
<description>
simple example build file
</description>
<!-- set global properties for this build -->
<property name="src" location="src"/>
<property name="build" location="build"/>
<property name="dist" location="dist"/>
<target name="init">
<!-- Create the time stamp -->
<tstamp/>
<!-- Create the build directory structure used by compile -->
<mkdir dir="${build}"/>
</target>
<target name="compile" depends="init"
description="compile the source">
<!-- Compile the Java code from ${src} into ${build} -->
<javac srcdir="${src}" destdir="${build}"/>
</target>
<target name="dist" depends="compile"
description="generate the distribution">
<!-- Create the distribution directory -->
<mkdir dir="${dist}/lib"/>
<!-- Put everything in ${build} into the MyProject-${DSTAMP}.jar file -->
<jar jarfile="${dist}/lib/MyProject-${DSTAMP}.jar" basedir="${build}"/>
</target>
<target name="clean"
description="clean up">
<!-- Delete the ${build} and ${dist} directory trees -->
<delete dir="${build}"/>
<delete dir="${dist}"/>
</target>
</project>
빌드 파일은 XML로 작성되며 빌드에 관한 간단한 메타데이터와 작업 목록 (XML의 <target> 태그)을 정의합니다. (Ant에서는 타겟이라는 단어를 사용하여 작업을 나타내고 작업이라는 단어를 사용하여 명령어를 나타냅니다.) 각 작업은 Ant에서 정의한 가능한 명령어 목록을 실행합니다. 여기에는 디렉터리 생성 및 삭제, javac 실행, JAR 파일 생성이 포함됩니다. 이 명령어 집합은 사용자가 제공한 플러그인으로 확장하여 모든 종류의 로직을 포함할 수 있습니다. 각 작업은 depends 속성을 통해 종속된 작업을 정의할 수도 있습니다. 이러한 종속 항목은 그림 1과 같이 비순환 그래프를 형성합니다.
그림 1. 종속 항목을 보여주는 비순환 그래프
사용자는 Ant의 명령줄 도구에 작업을 제공하여 빌드를 실행합니다. 예를 들어 사용자가 ant dist를 입력하면 Ant는 다음 단계를 실행합니다.
- 현재 디렉터리에서
build.xml이라는 파일을 로드하고 이를 파싱하여 그림 1에 표시된 그래프 구조를 만듭니다. - 명령줄에 제공된
dist라는 태스크를 찾고compile라는 태스크에 종속 항목이 있음을 확인합니다. compile라는 태스크를 찾고init라는 태스크에 종속 항목이 있음을 확인합니다.init라는 작업을 찾고 종속 항목이 없음을 확인합니다.init작업에 정의된 명령어를 실행합니다.- 해당 작업의 모든 종속 항목이 실행된 경우
compile작업에 정의된 명령어를 실행합니다. - 해당 작업의 모든 종속 항목이 실행된 경우
dist작업에 정의된 명령어를 실행합니다.
결국 dist 작업을 실행할 때 Ant에서 실행하는 코드는 다음 셸 스크립트와 같습니다.
./createTimestamp.shmkdir build/javac src/* -d build/mkdir -p dist/lib/jar cf dist/lib/MyProject-$(date --iso-8601).jar build/*
구문을 삭제하면 빌드 파일과 빌드 스크립트가 크게 다르지 않습니다. 하지만 이렇게 함으로써 이미 많은 것을 얻었습니다. 다른 디렉터리에 새 빌드 파일을 만들고 이를 서로 연결할 수 있습니다. 임의의 복잡한 방식으로 기존 작업에 종속된 새 작업을 쉽게 추가할 수 있습니다. ant 명령줄 도구에 단일 작업의 이름만 전달하면 실행해야 하는 모든 항목이 결정됩니다.
Ant는 2000년에 처음 출시된 오래된 소프트웨어입니다. Maven, Gradle과 같은 다른 도구는 그동안 Ant를 개선해 왔으며 외부 종속 항목의 자동 관리, XML이 없는 더 깔끔한 구문과 같은 기능을 추가하여 기본적으로 Ant를 대체했습니다. 하지만 이러한 최신 시스템의 본질은 동일합니다. 엔지니어가 원칙에 따라 모듈식 방식으로 빌드 스크립트를 작업으로 작성하고 이러한 작업을 실행하고 작업 간 종속 항목을 관리하는 도구를 제공합니다.
작업 기반 빌드 시스템의 어두운 면
이러한 도구를 사용하면 엔지니어가 스크립트를 작업으로 정의할 수 있으므로 매우 강력하며 상상할 수 있는 거의 모든 작업을 수행할 수 있습니다. 하지만 이러한 강력한 기능에는 단점이 있으며, 빌드 스크립트가 더 복잡해지면 작업 기반 빌드 시스템을 사용하기 어려워질 수 있습니다. 이러한 시스템의 문제는 실제로 엔지니어에게는 너무 많은 권한을 부여하고 시스템에는 충분한 권한을 부여하지 않는다는 것입니다. 시스템은 스크립트가 무엇을 하는지 알 수 없으므로 빌드 단계를 예약하고 실행하는 방식이 매우 보수적이어야 하므로 성능이 저하됩니다. 시스템에서 각 스크립트가 해야 할 일을 하고 있는지 확인할 방법이 없으므로 스크립트가 복잡해지고 디버깅해야 하는 또 다른 요소가 되는 경향이 있습니다.
빌드 단계 병렬화의 어려움
최신 개발 워크스테이션은 여러 빌드 단계를 병렬로 실행할 수 있는 다중 코어를 갖춘 매우 강력한 시스템입니다. 하지만 작업 기반 시스템은 병렬화할 수 있을 것 같은 경우에도 작업 실행을 병렬화하지 못하는 경우가 많습니다. 작업 A가 작업 B와 C에 종속된다고 가정해 보겠습니다. 작업 B와 C는 서로 종속되지 않으므로 시스템이 작업 A에 더 빨리 도달할 수 있도록 동시에 실행해도 안전한가요? 동일한 리소스를 건드리지 않는다면 가능합니다. 하지만 그렇지 않을 수도 있습니다. 두 프로세스 모두 상태를 추적하는 데 동일한 파일을 사용하고 동시에 실행하면 충돌이 발생할 수 있습니다. 일반적으로 시스템이 알 수 있는 방법이 없으므로 이러한 충돌을 감수해야 합니다(드물지만 디버그하기 매우 어려운 빌드 문제 발생). 또는 단일 프로세스의 단일 스레드에서 실행되도록 전체 빌드를 제한해야 합니다. 이는 강력한 개발자 머신을 크게 낭비하는 것이며 여러 머신에 빌드를 분산할 가능성을 완전히 배제합니다.
증분 빌드 실행의 어려움
좋은 빌드 시스템을 사용하면 엔지니어가 안정적인 증분 빌드를 실행할 수 있으므로 작은 변경사항이 발생해도 전체 코드베이스를 처음부터 다시 빌드할 필요가 없습니다. 이는 빌드 시스템이 느리고 앞서 언급한 이유로 빌드 단계를 병렬화할 수 없는 경우 특히 중요합니다. 하지만 태스크 기반 빌드 시스템도 여기서는 어려움을 겪습니다. 작업은 무엇이든 할 수 있으므로 일반적으로 작업이 이미 완료되었는지 확인할 방법이 없습니다. 많은 작업은 단순히 소스 파일 집합을 가져와 컴파일러를 실행하여 바이너리 집합을 만듭니다. 따라서 기본 소스 파일이 변경되지 않은 경우 다시 실행할 필요가 없습니다. 하지만 추가 정보가 없으면 시스템에서 이를 확실하게 알 수 없습니다. 작업에서 변경되었을 수 있는 파일을 다운로드하거나 실행할 때마다 다를 수 있는 타임스탬프를 작성할 수 있습니다. 정확성을 보장하기 위해 시스템은 일반적으로 각 빌드 중에 모든 작업을 다시 실행해야 합니다. 일부 빌드 시스템에서는 엔지니어가 태스크를 다시 실행해야 하는 조건을 지정할 수 있도록 하여 증분 빌드를 사용 설정하려고 합니다. 가능한 경우도 있지만, 겉으로 보이는 것보다 훨씬 까다로운 문제인 경우가 많습니다. 예를 들어 다른 파일에서 직접 파일을 포함할 수 있는 C++과 같은 언어에서는 입력 소스를 파싱하지 않고 변경사항을 감시해야 하는 전체 파일 집합을 확인할 수 없습니다. 엔지니어는 지름길을 택하는 경우가 많으며 이러한 지름길은 작업 결과가 재사용되어서는 안 되는 경우에도 재사용되는 드물고 답답한 문제로 이어질 수 있습니다. 이 문제가 자주 발생하면 엔지니어는 매 빌드 전에 정리하여 새로운 상태를 가져오는 습관을 갖게 되므로 증분 빌드의 목적이 완전히 무산됩니다. 작업을 다시 실행해야 하는 시점을 파악하는 것은 미묘한 문제이며, 인간보다는 머신이 더 잘 처리할 수 있는 작업입니다.
스크립트 유지 및 디버깅의 어려움
마지막으로 작업 기반 빌드 시스템에서 부과하는 빌드 스크립트는 작업하기 어려운 경우가 많습니다. 빌드 스크립트는 검토를 덜 받는 경우가 많지만 빌드되는 시스템과 마찬가지로 코드이며 버그가 숨기 쉬운 곳입니다. 다음은 작업 기반 빌드 시스템을 사용할 때 매우 흔한 버그의 예입니다.
- 작업 A는 작업 B가 특정 파일을 출력으로 생성해야 합니다. 작업 B의 소유자는 다른 작업이 작업 B에 의존한다는 것을 알지 못하므로 다른 위치에서 출력을 생성하도록 변경합니다. 이 문제는 누군가 태스크 A를 실행하려고 할 때 실패하는 것을 발견할 때까지 감지할 수 없습니다.
- 작업 A는 작업 B에 종속되고 작업 B는 작업 C에 종속됩니다. 작업 C는 작업 A에 필요한 특정 파일을 출력으로 생성합니다. 작업 B의 소유자가 더 이상 작업 C에 의존할 필요가 없다고 결정하면 작업 B는 작업 C에 전혀 관심이 없더라도 작업 A가 실패합니다.
- 새 작업의 개발자가 도구의 위치나 특정 환경 변수의 값과 같이 작업을 실행하는 머신에 대해 실수로 가정을 합니다. 이 작업은 자신의 머신에서는 작동하지만 다른 개발자가 시도할 때마다 실패합니다.
- 작업에 인터넷에서 파일을 다운로드하거나 빌드에 타임스탬프를 추가하는 등 비결정적 구성요소가 포함되어 있습니다. 이제 빌드를 실행할 때마다 결과가 달라질 수 있으므로 엔지니어가 서로의 실패나 자동 빌드 시스템에서 발생하는 실패를 항상 재현하고 수정할 수 없습니다.
- 종속 항목이 여러 개인 작업은 경합 상태를 만들 수 있습니다. 작업 A가 작업 B와 작업 C 모두에 종속되고 작업 B와 C가 모두 동일한 파일을 수정하는 경우 작업 A는 작업 B와 C 중 어느 것이 먼저 완료되는지에 따라 다른 결과를 얻게 됩니다.
여기에 설명된 작업 기반 프레임워크 내에서 이러한 성능, 정확성 또는 유지관리 문제를 해결할 수 있는 범용적인 방법은 없습니다. 엔지니어가 빌드 중에 실행되는 임의의 코드를 작성할 수 있는 한 시스템은 항상 빠르고 올바르게 빌드를 실행할 수 있는 충분한 정보를 보유할 수 없습니다. 이 문제를 해결하려면 엔지니어의 손에서 일부 권한을 가져와 시스템의 손에 다시 넣고 시스템의 역할을 작업을 실행하는 것이 아니라 아티팩트를 생성하는 것으로 다시 개념화해야 합니다.
이 접근 방식으로 인해 Blaze 및 Bazel과 같은 아티팩트 기반 빌드 시스템이 만들어졌습니다.