Tag Archives: brew

Mac에 Homebrew를 사용하여 Jenkins 설치하기

jenkins-logo-title

젠킨스는 CI(Continuous Integration) 툴중에 아마도 가장 유명한 CI툴이지 않을까 생각되는 오픈소스 프로젝트입니다. 빌드시에 사용할 수 있는 수백가지가 넘는 플러그인을 제공하고 있으며 대부분의 프로젝트를 자동화 할 수 있을 정도의 확장성과 배포 기능까지 갖추고 있습니다.

Xcode 프로젝트등의 빌드를 수행하기 위해서는 Jenkins 를 맥에서 구동하는 것이 필수일 것입니다. 이번에는 맥에서 Jenkins를 설치하여 구동하는 과정까지 기록을 해보려고 합니다. 복잡한 방법을 사용할것 없이 Homebrew를 사용하면 Jenkins를 손쉽게 설치할 수 있습니다. (이미 설치되어있는 분은 패스하세요~)

위의 명령을 사용하여 간편하게 Homebrew를 설치할 수 있습니다. 이제 젠킨스를 설치해 보겠습니다.

위와 같이 명령어 한줄로 간단하게 젠킨스를 설치할 수 있습니다. 젠킨스를 백그라운드 서비스로 구동하려면 마찬가지로 간단하게 다음의 명령어 한줄이면 등록이 됩니다.

나중에 젠킨스를 삭제하려면 다음과 같은 명령을 사용하면 됩니다. (지금 하는것 아님!)

이제 젠킨스를 실행했으니 웹사이트에 접속을 해보겠습니다. 로컬 컴퓨터라면 http://localhost:8080에 접속하시면 됩니다.

jenkins-installation-with-homebrew01

위와 같은 화면이 나오게 됩니다. 설치과정에서 외부에서 접속해서 이래저래 하는것을 막기 위한 조치인듯 하네요. 현재 젠킨스를 설치하고 있는 계정의 홈디렉토리에 초기 비밀번호를 기록해 두었으니 그것을 읽어서 그 값을 입력하라고 합니다.

이런식으로 읽어보시면 해당 키 값을 읽을 수 있습니다. 이것을 입력해주면 다음으로 진행이 됩니다.

jenkins-installation-with-homebrew02

젠킨스를 어떻게 설치할지 결정할 수 있습니다. 어떤 추가기능을 설치할것인지 결정하는 부분인데요 왼쪽은 일반적으로 사용되는 플러그인들을 설치하는것이고 오른쪽은 하나하나 선택하여 설치할 수 있는 방법을 제공합니다. 필요한 추가적인 플러그인은 나중에 설치하기로 하고 우선 왼쪽의 선택지로 진행하겠습니다.

jenkins-installation-with-homebrew03

이런식으로 필요한 플러그인들을 자동으로 설치하기 시작합니다. 간혹 네트워크 환경에 따라 설치가 되지 않는 경우가 있는데 이경우 네트워크 환경을 점검하시기 바랍니다.

jenkins-installation-with-homebrew03error

저같은 경우에는 회사에서는 Jar 파일 다운로드에 방화벽상의 제약이 있어서 설치가 제대로 되지 않는 문제가 있었습니다.

jenkins-installation-with-homebrew04

설치가 된 이후에는 위와 같은 관리자 계정을 만드는 창이 나옵니다. 여기서는 적절히 자신에게 맞는 정보를 입력하여 관리자 계정을 만들어 주시면 됩니다.

jenkins-installation-with-homebrew05

설치가 완료되었습니다. 정말 간단하고 쉽네요. 이제 만들어진 관리자 계정으로 로그인하여 진입해보겠습니다.

jenkins-installation-with-homebrew06

젠킨스를 정상적으로 설치하였고 관리자 계정을 만들어서 로그인하는것에 성공하였습니다. 프로젝트 빌드하는 방법에 대해서는 또 다른 글을 올리도록 하겠습니다.

Gradle을 이용하여 Java 프로젝트 빌드하기

이 가이드는 Gradle을 이용하여 간단한 자바 프로젝트를 빌드하는 과정을 정리한 문서입니다. 기본적으로 맥 환경에서 진행되므로 윈도우에서는 조금 다를 수 있습니다.

Homebrew를 이용하여 gradle 설치

Homebrew를 이용하면 Gradle의 설치가 정말 간단합니다. 다음의 명령어를 사용하여 설치를 합니다.

설치가 완료되면 실행을 한번 해보겠습니다. 환영 메시지를 볼 수 있습니다.

샘플 어플리케이션 제작

Gradle을 이용한 빌드를 해보기 위한 샘플 자바 어플리케이션을 제작해 보겠습니다. Gradle이 이 글의 주인공이기에 프로젝트의 코드는 정말 단순합니다. 적당한 위치(저는 hello디렉토리를 생성하고 그 안에서 작업을 하였습니다)의 디렉토리 안에서 mkdir -p src/main/java/hello 를 사용하여 필요한 디렉토리 구조를 한번에 생성합니다. 다음과 같은 디렉토리 구조가 생성됩니다.

이제 src/main/java/hello 디렉토리 안에 원하는 자바 클래스 파일을 생성하면 됩니다. 하지만 정말 간단한 형태의 HelloWorld.javaGreeter.java 클래스를 생성해 보도록 하겠습니다.

Gradle로 무엇을 할 수 있는지 확인

Gradle이 정상적으로 설치 되었고 샘플 프로젝트가 준비되었습니다. 프로젝트를 위한 build.gradle 파일을 생성하기 이전에 어떤 태스크를 수행할 수 있는지 확인해 볼 수 있습니다. build.gradle 파일이 없는 폴더에서 Gradle을 실행 하였기에 매우 기본적인 태스크들만을 확인할 수 있습니다.

위와 같은 명령들이 수행 가능하다고 표시는 되지만 빌드 설정 파일이 없이는 실제로 할 수 있는것이 거의 없습니다. 몇몇 태스크는 build.gradle 같은 파일을 정의됨으로써 더 유용해 질 수 있습니다. build.gradle 설정에 플러그인을 추가할때마다 태스크는 점점 늘어나게 됩니다. 그러므로 프로젝트의 진행중에 가끔씩 tasks 명령을 수행하여 어떤 태스크가 수행가능한지 확인해봅시다. 다음은 이러한 플러그인중에 Java 빌드 기능을 활성화 하는 플러그인을 추가하는 과정을 진행하겠습니다.

Java 코드 빌드

매우 심플하고 기본적인 한줄짜리 build.gradle 파일을 생성해 봅시다.

한줄짜리 빌드 설정이지만 매우 파워풀한 변화를 가져옵니다. gradle tasks 를 다시 실행해 봅니다. 프로젝트를 빌드하고 JavaDoc을 생성하고 테스트를 실행할 있는 태스크를 포함하여 새로운 태스크가 리스트에 추가된것을 볼 수 있습니다.

이제 gradle tasks 를 자주 실행하게 될것입니다. 이 태스크는 코드를 컴파일하고 테스트하고 조립하여 JAR 파일을 생성합니다. 다음과 같이 실행을 해봅시다.

몇초의 시간이 지난뒤에 빌드가 완료되었음을 알리는 “BUILD SUCCESSFUL”이 출력됩니다. 빌드의 결과물을 확인하기 위하여 새롭게 생성된 build 디렉토리를 확인해볼 필요가 있습니다. 그 안에서 다음의 중요한 3가지 디렉토리를 포함하여 몇몇 디렉토리를 확인할 수 있습니다.

  • classes : 프로젝트의 컴파일된 .class 파일
  • reports : 빌드에 의해 생성된 레포트가 존재 (test에 대한 수행 결과)
  • libs : 조립된 프로젝트 라이브러리 파일

classes 디렉토리안에는 Java 코드로 부터 컴파일된 .class 파일이 존재합니다. 여기서는 HelloWorld.classGreeter.class 가 존재할 것입니다. 여기서 프로젝트는 어떤 라이브러리 의존성을 가지고 있지 않습니다. 그러므로 dependency_cache 디렉토리안에 아무것도 존재하지 않게됩니다.

report 디렉토리에는 프로젝트의 유닛 테스트 결과를 포함합니다. 하지만 지금은 어떤 테스트도 존재하지 않기에 확인해볼 필요는 없을것 같습니다.

libs 디렉토리는 프로젝트의 폴더 이름을 띈 JAR 파일이 만들어집니다.

의존성 선언

이 심플한 프로젝트에서는 사실 그 어떤 추가적인 라이브러리도 필요로 하지 않습니다. 하지만 대부분의 어플리케이션들은 외부의 다양한 라이브러리들의 일반적인 또는 복잡한 기능들에 의존성을 가지고 있습니다.

예시를 위해 “Hello World!” 이외에 추가적으로 현재 날짜와 시간을 출력하도록 하겠습니다. 네이티브 Java 라이브러리를 이용해서 충분히 이러한 기능을 구현할 수 있지만 우리는 외부라이브러리인 Joda Time 라이브러리를 사용하도록 하겠습니다. 첫번째로 HelloWorld.java는 다음과 같이 수정하였습니다.

이제 HelloWorld는 Joda Time의 LocalTime 클래스를 이용하여 현재 시간을 출력하도록 변경되었습니다. 이 시점에서 gradle build를 수행한다면 빌드는 실패하게 됩니다. 왜냐하면 아직 Joda Time이 빌드의 컴파일 의존성 설정이 안되어있기 때문입니다. build.gradle에 다음을 추가함으로써 이 문제를 해결할 수 있습니다.

첫번째줄은 빌드의 의존성 해결을 위해 Maven 중앙 저장소를 활용할것을 선언하는 부분입니다. Gradle은 메이븐중앙저장소를 의존성 라이브러리로 활용하는등 많은 문법과 기능들이 Maven 빌드툴로부터 물려받았습니다.

dependencies 블록에서는 Jodat TIme에 대한 의존성 선언을 하였습니다. (오른쪽에서 왼쪽으로 읽었을 때) 이 문장은 버전 2.2의 joda-time 라이브러리를 joda-time 그룹에서 찾겠다는것을 의미합니다.

의존성 설정중에 또다른 유심히 볼 부분은 compile 입니다. 이는 해당 의존성 라이브러리가 컴파일 시점에 사용되어짐을 의미합니다. (만약 WAR 파일을 빌드한다면 /WEB-INF/libs 폴더가 포함) 다른 의존성 타입은 다음이 있습니다.

  • providedCompile : 프로젝트의 코드가 컴파일되는데 필요로 되는 의존성 라이브러리를 정의합니다. 단 실제 런타임시에 컨테이너로부터 제공받기 때문에 빌드 결과물에 포함될 필요는 없는 라이브러리임을 뜻합니다. 예로 Java ServletAPI나 JSTL 라이브러리가 있습니다.
  • testCompile : 테스트 실행시에 필요한 의존성을 정의합니다. 하지만 실제 프로젝트의 런타임에는 사용되지 않는 라이브러리임을 뜻합니다.

이제 gradle build를 실행합니다. Gradle은 Joda Time 라이브러리를 메이븐 중앙 저장소에서 다운받아 의존성을 해결한 뒤에 성공적으로 빌드를 수행하게 됩니다.

Gradle Wrapper를 이용한 프로젝트 빌드

Gradle Wrapper는 Gradle을 이용한 빌드를 시작하기 위해 선호되는 방법입니다. 이 래퍼는 윈도우를 지원하는 배치 스크립트와 OSX, Linux를 지원하는 쉘스크립트를 포함하고 있습니다. 이러한 스크립트들은 Gradle이 설치되어있지 않은 시스템에서도 Gradle 빌드를 가능하게 해줍니다. build.gradle파일에 다음의 설정을 추가함으로써 래퍼를 설치할 수 있습니다.

그리고 다음의 명령을 통해 래퍼 스크립트를 다운받고 초기화 할 수 있습니다.

명령이 정상적으로 수행되고나면 몇몇 파일이 생성되었음을 알려줍니다. 두개의 스크립트 파일이 루트 디렉토리에 생성되고 래퍼 jar 파일과 설정 파일이 gradle/wrapper 디렉토리 안에 생성됩니다.

당신의 프로젝트를 빌드하기 위한 Gradle Wrapper가 준비되었습니다. 기존에 설치했던 Gradle과 똑같은 방식으로 사용할 수 있습니다. 빌드를 수행하기 위해 기존에 수행했던 방법과 거의 흡사하게 다음의 명령을 수행하면 됩니다.

특정 버전의 Gradle Wrapper를 처음으로 실행하게 되면 해당 버전의 Gradle 바이너리를 다운받고 캐시하게 됩니다. Gradle Wrapper는 어떤 유저라도 프로젝트를 개발하기 위해 같은 버전의 Gradle 환경을 구축할 필요 없이 소스 코드의 개발에 전념할 수 있도록 설계되어있습니다.

다음은 지금까지 다루었던 내용이 모두 기술 된 build.gradle 파일입니다.

참고 : https://spring.io/guides/gs/gradle/