빌드 관리 도구란 빌드 자동화를 수행해 실행가능한 프로그램으로 바꿔주는 도구
그렇다면 빌드 자동화란..
Build automation is the process of automating the creation of a software build and the associated processes including: compiling computer source code into binary code, packaging binary code, and running automated tests. – Wikipedia
즉, 빌드 자동화란 코드를 컴파일해서 binary code로 만들고, 패키징하고 코드를 테스트하여 실행가능한 프로그램이 나오기 까지의 과정(빌드)을 자동화하는 것
정해진 라이프사이클에 의하여 작업을 수행하며, 전반적인 프로젝트 관리 기능도 포함하고 있음
◎ Default(Build) : 일반적인 빌드 프로세스를 위한 모델이다.
◎ Clean : 빌드 시 생성되었던 파일들을 삭제하는 단계
◎ Validate : 프로젝트가 올바른지 확인하고 필요한 모든 정보를 사용할 수 있는지 확인하는 단계
◎ Compile : 프로젝트의 소스코드를 컴파일 하는 단계
◎ Test : 유닛(단위) 테스트를 수행 하는 단계(테스트 실패시 빌드 실패로 처리, 스킵 가능)
◎ Pacakge : 실제 컴파일된 소스 코드와 리소스들을 jar, war 등등의 파일 등의 배포를 위한 패키지로 만 드는 단계
◎ Verify : 통합 테스트 결과에 대한 검사를 실행하여 품질 기준을 충족하는지 확인하는 단계
◎ Install : 패키지를 로컬 저장소에 설치하는 단계
◎ Site : 프로젝트 문서와 사이트 작성, 생성하는 단계
◎ Deploy : 만들어진 package를 원격 저장소에 release 하는 단계
Groovy란?
- JVM에서 사용되는 스크립트 언어로, 문법이 Java와 매우 유사.
Java와 호환이 되며 Java 클래스 파일을 그대로 Groovy 클래스 파일로 사용 가능.
흔히들 Gradle이 대세라고 하지만, 여전히 Maven의 사용률은 Gradle을 앞서고 있으며 구글 트랜드 지수도 Maven이 Gradle을 앞선다. 그럼에도 Gradle 사용을 고려해야할 이유들은 다음과 같다.
속도가 빠르다
Gradle에서 직접 제공하는 Gradle과 Maven의 비교문서에 따르면 Gradle은 메이븐보다 최대 100배까지 빠르게 작동한다고 함
Build라는 동적인 요소를 XML로 정의하기에는 어려운 부분이 많다
• 설정 내용이 길어지고 가독성 떨어짐
• 의존관계가 복잡한 프로젝트 설정하기에 부적절
• 상속구조를 이용한 멀티 모듈 구현
• 특정 설정을 소수의 모듈에서 공유하기 위해서는 부모 프로젝트를 생성하여 상속하게 해야 함
Gradle은 Groovy를 사용하기 때문에, 동적인 빌드는 Groovy 스크립트로 플러그인을 호출하거나 직접 코드를 짜면 된다
• Configuration Injection 방식을 사용해서 공통 모듈을 상속해서 사용하는 단점을 커버함
• 설정 주입 시 프로젝트의 조건을 체크할 수 있어서 프로젝트별로 주입되는 설정을 다르게 할 수 있음
Gradle이 Maven의 장점을 계승한 점과 시기적으로 늦게 나온 만큼 사용성, 성능 등 비교적 뛰어난 스펙을 가지고 있다. 특히, 속도가 빠르며 Groovy 기반으로 설정이 쉽고, 설정 주입 방식을 사용하여 멀티 프로젝트에 사용하기 좋다. 하지만 메모리를 많이 잡아먹는다는 단점 또한 검색으로 알 수 있었다.
프로젝트의 빌드타임이 비용문제로 이어질 경우 Gradle을 사용해야 할 것 같고, '익숙함'에서 벗어나는 것이 두려워 Gradle 사용을 망설이는 Maven 기반 개발자들도 한번쯤 사용을 고려해볼 가치가 충분하다고 생각한다.
나 또한 개인 프로젝트를 Gradle로 진행하며 쓸데없는 XML 형식을 지키지 않아도 된다는 점에서 굉장히 매력을 느꼈다.