캠핑과 개발

빌드자동화 +1

허드슨을 사용하기 위해서 기본적인 셋팅 방법과 빌드를 셋팅하는 방법을 설명한다.
설치법은 간단하기 때문에 따로 설명하지 않도록 하며 설치가 되지 않았다면 아래 경로를 사용하여 다운 받아서 Tomcat에 설치하면 된다.

다운로드 : https://hudson.dev.java.net/servlets/ProjectDocumentList?folderID=2761

1. 허드슨 기본 설정 
허드슨 기본 설정법이라 함은 Ant, Maven등의 기본 빌드 스크립트를 지정하는 방법과 JDK의 기본 설정을 하는 법을 알아본다. 

일단 처음에 허드슨 메인 화면으로 가면 다음과 같은 이미지를 볼수가 있다.
다음 메뉴에서 Hudson 관리 메뉴를 클릭한다.


해당 메뉴를 클릭하면 다음과 같은 화면을 볼 수가 있다.
아래 메뉴에서 Configure System 메뉴를 클릭한다.



메뉴가 선택이 되면 나타나는 메뉴 화면 중에 아래 부분을 해당 경로에 맞게 적용해준다.

설정이 완료 되었다면 save를 눌러서 저장을 한다.

위에서 설정한 부분이 각각 Maven, JDK, Ant를 설정한 부분이다.
해당 라이브러리가 설치되지 않았다면 각 다운을 받아서 설치하길 바란다.

그리고 초기에는 hudson이 로그인 사용없이 모두 허용으로 되어 있다. 이 부분을 로그인 사용자만 사용할수 있게 하려면 다음 부분을 체크 해주게 되면 다음부터는 로그인을 해야만 설정을 변경을 할 수가 있다.




2. 빌드 셋팅하기 

기본 설정이 완료 되었으니 이제 새작업을 등록해보도록 하자.
hudson 메인 메뉴에서 새 작업 메뉴 버튼을 눌러서 등록 화면으로 이동하자.



메뉴를 선택하게 되면 새로운 작업에 대한 프로젝트 생성 화면이 나올것이다.
화면에서 작업명(job name)을 등록하고 Build a free-style software project를 선택하고 OK를 눌러 다음 화면으로 이동한다.




다음 페이지로 이동이 되었다면 Source Code Management 부분에서 소스 관리  시스템을 선택하도록 한다. Subversion 을선택하도록 하자.
하지만 그 위에 있는 메뉴의 대한 설명은 다음과 같다.

  • 프로젝트 이름(Project name): 난 이미 HeliosJMXTrunk 라고 프로젝트 이름을 지었지만, 여기에서 바꿀 수 있다.
  • 설명(Description): 빌드 업무에 대해 기술할 수 있는 자유 형식 폼 필드
  • 오래된 빌드 버리기(Discard old builds): 허드슨은 이 체크박스를 선택하지 않는다면, 이전 기록을 보관할 것이다.
  • 이 빌드작업은 파라미터화 됨(This build is parameterized): 만일 이 옵션을 선택하면, 허드슨은 빌드 프로세스에 전달 가능한, 이름-값 쌍으로 이루어진 임의의 파라미터 세트 제공을 허락 할 것이다. 설정 파라미터들은 러닝 빌드 환경에서 환경 변수로 지정될 것이다.
  • 프로젝트 기반 보안 활성화(Enable project-based security): 허드슨은 유저들이 허드슨 웹 페이지를 접근할 때 인증작업을 하기 위한 전체 보안 스키마를 지원한다. 또한 이 보안 스키마는 어떤 유저들이 어떤 빌드 업무를 건드리는 것이 가능한지에 대한 제어를 제공할 수 있다. 나는 이 허드슨 인스턴스에서 보안은 설정하지 않았다.
  • 빌드 불가(Disable build): 이 항목이 체크되면, 옵션이 비 활성화 될때까지 이 빌드 업무는 실행되지 않을 것이다.
  • 고급 옵션(Advanced options): 나는 이 옵션 중에 사용하는 것은 없다. 하지만 이 체크 박스를 선택하면, 다음과 같은 옵션들이 인터페이스에 나타나게 된다.
    • 정숙 기간(Quiet Period): 빌드 수행이 예정되었을 때 실제 수행 이전에 발생하는 정숙 기간(=휴지기간)을 설정할 수 있다. (즉, Delay time과 동일의미, 0 이면 build now! 의 의미)
    • 커스텀 워크스페이스를 사용(Use custom workspace): 기본적으로, 허드슨은 ${jboss-home}/.hudson/jobs/[project name] 에 빌드 업무용 워크스페이스를 만든다. 이 옵션은 당신 다른 장소를 지정하는 것을 가능케 해준다.



  • Subversion
    을 선택하면 위와 같은 화면이 나타나게 되는데 이 부분에 각 사용자에 맞는 정보를 입력하도록 한다.

    Repository URL : svn://도메인/trunk/myproject_name
    Local module directory (optional) :
    Use update : 체크

    이렇게 되면 svn://도메인/trunk/myproject_name에서 프로젝트를 내려 받게 된다.

    Use update
    이 부분은 체크를 한 이유는 체크가 되지 않았을때는 매번 저장소에서 모든 소스를 내려 받게 된다 이렇게 되면 소스를 받는 시간도 길어질뿐 아니라 빌도하는데도 시간이 한참 걸리게 되므로 이부분을 체크를 하여 변경된 파일만 update를 받도록 하기 위함이다.

    Repository Browser
    이 부분은 기존 버전과 새롭게 변경된 파일이 있을 경우 비교해가면서  어떤 부분이 변경 되었는지 소스의 히스토리를 볼수가 있다. 이 옵션을 체크를 해 놓으면 빌드 완료후 job의 Change에서 코드 변경된 내용을 확인 할수있다.

    여기까지 저장소 설정은 끝났다. 이제는 빌드에 관한 설정을 해야 되는데 이 부분은 Build TriggersBuild에서 설정을 한다. 옵션에 대한 설명은 아래와 같다.

    1) Build after other projects are built
    이 옵션에는 다른 Job(Project)의 이름을 인자로 넣는다.
    이렇게 하면 지정된 프로젝트의 빌드가 정상적으로 끝나면 자동으로 이 프로젝트가 Invoke된다. 만약에 빌드만 하는 Job과 테스트만 하는 Job이 있고 테스트는 자주 사용하고 빌드후에 반드시 테스트를 해야할 때, 테스트 Job에서 이 옵션으로 선행작업을 빌드로 해놓으면 빌드를 수행할 때 마다 빌드가 성공하면 테스트를 수행하게 된다. 테스트만 수행하면 빌드와 상관없이 테스트만 수행된다.
    이 옵션은 프로젝트 실행의 전후 관계(Chainning)을 하는데 매우 유용하게 사용할 수 있다.

    2) Poll SCM
    이 옵션을 사용하면 여기에 지정한 주기별로 소스 관리 시스템을 폴링(체크)하여 변경이 있을 경우에만 빌드를 수행한다.

    3) Build periodically
    마지막으로 Build periodically는 정해진 시간 주기별로 소스가 변경과 상관없이 무조건 주기적으로 빌드를 수행하며 Poll SCM과 마찬가지로 crontab과 같은 형식으로 스케쥴을 등록한다.

    아래 그림과 같이 Poll SCM 메뉴를 체크를 한다.



    Schedule에 대한 옵션은 unix의 crontab 명령과 같은 형식인다.
    분 시간 날짜 월 요일

    예)

    사용 예는 다음과 같다.
    # 매일 12시에 실행
    00 12 * * *
    # 매주 일요일 1시에 실행
    00 01 * * 7
    # 매일 12시와 5시에 실행
    00 05 * * *
    00 12 * * *
    # 매 5분마다 실행
    */5 * * * *

    이제 Build 메뉴에서 Invoke Ant를 선택한다.



  • Ant 버전(Ant version): 빌드를 수행 시에 사용하려고 미리 정의해 놓은 Ant 인스턴스
  • 타겟들(Targets): 지정한 Ant 스크립트 중에서 수행되어야 하는 타겟들의 목록. 스크립트의 디폴트 테스크가 실행될 경우에는, 빈 칸으로 남겨 놓을 수 있다.
  • 빌드파일(Build file): 유효 워크스페이스를 기준으로 놓고 봤을 때, 수행되어야 하는 Ant 스크립트의 상대적인 위치.
  • 프로퍼티들(Properties): Ant 스크립트로 전달될 추가 시스템 프로퍼티 정의값. 나는 서브버전 인증정보를 스크립트로 전달하기 위해 이들 프로퍼티들을 사용했다. 왜냐하면 내 작업 절차에는 몇 가진 변경사항들을 저장소로 반영하는 단계가 포함되어 있기 때문이다. 추가적으로, 나는 내 단위 테스트들 위한 설정 파라미터들에 해당하는 몇몇 파라미터들을 정의했다.
  • 자바 옵션들: 자바 명령행 옵션들을 여기에서 전달할 수 있다. 여기에서 나는 Ant의 -debug 옵션을 할당했다. 왜냐하면 나는 Ant 스크립트에 있는 디버깅 문제에 대해 작업하고 있었기 때문에, 해당 옵션을 사용해서 Ant가 추가적인 분석정보들을 로그에 생성하게 하였다. 다른 흔한 옵션은 기동되는 JVM의 초기 힙 사이즈(-Xms)와 최대 힙사이즈(-Xmx)를 특정하는 지시문들이다. 이 옵션은 빌드 스크립트를 수행하기 위해 허드슨에 의해 실행되는 모든 새로운 JVM 인스턴스가 따르게 된다.



  • 이제 기본적은 설정은 끝났다 다음 부분은 다음 추가적인 옵션이니 없어도 무방하다.
    아직 안해봤으니 설명을 할수가 없으니 다음에 사용하면서 올리도록 하겠다.



  • 아티팩트 아카이브 하기(Archive the artifacts): 이 옵션을 선택해서 파일이나 디렉터리 마스크(mask = include와 exclude를 지정할 수 있는 Ant 스타일의 마스크)를 지정할때, 마스크와 일치하는 아티팩트들은 빌드가 완료되면, 허드슨 아티팩트 저장소에 추가되고 빌드 업무와 빌드 시퀀스 넘버를 사용해서 키값(key)으로 만들어지게 될 것이다. 옵션에 따라, 허드슨 서버의 디스크 공간을 절약하기 위해서 성공적으로 빌드된 이전의 모든 아티팩트들을 버릴 수 있다.
  • 사용 추적을 위해 파일들의 사용 흔적을 기록 (Record fingerprints of files to track usage): 이 옵션을 선택하면, 비슷한 형태의 Ant 스타일 마스크(mask)를 사용해서, 허드슨으로 하여금 생성된 아티팩트들의 사용흔적(fingerprints)을 유지하도록 지시할 수 있다. 그렇게 해서, 시스템 내의 다른 어느 곳에서 이들 아티팩트들이 사용되는지를 당신이 좀 더 쉽게 추적할 수 있게 해준다.
  • Javadoc 만들어내기(Publish javadoc): 만일 당신의 빌드 스크립트가 javadoc 컨텐트를 생성해낸다면, 이 옵션은 허드슨으로 하여금 해당 컨텐트를 만들어 낸 다음 곧바로 업무 홈 페이지에 게시할 것을 지시할 것이다. 빌드가 성공한 모든 경우에 있어 javadoc 컨텐트는 계속 유지될 것이다. 그러나 기본적으로 마지막에 해당하는 것만 유지된다.
  • JUnit 테스트 결과 보고서 만들어내기(Publish JUnit test result report): 만일 당신의 빌드 스크립트가 JUnit 테스트를 수행한다면, 이 옵션은 허드슨으로 하여금 XML테스트 결과 문서를 처리해서 각각의 성공적인 빌드의 진행 보고서를 생성해 내고, 지속적으로 결과들을 모으도록 지시한다. 모인 결과가 바로 업무 홈 페이지에 있는 보고서에 해당하며, 오랜 시간에 걸쳐 수행된 빌드 업무용 단위 테스트의 기록이 될 수 있는 트랜드(historical trends)로 보여주는 보고서이다.
  • 다운스트림 테스트 결과 모으기(Aggregate downstream test results): 어떤 경우에는, 한 업무의 단위 테스트 스위트의 수행 시간이 실제 빌드 시간 보다 엄청 더 길다. 이런 경우에는, 빌드와 테스트를 각각 다른 업무로 분리하는 것을 선택할 수 있다. 그래서 상대적으로 빌드가 빠르게 종료될 수 있도록 말이다. 하지만, 구현되어 있는 하나 이상의 테스트 업무들은 빌드가 성공적으로 완료되면 그 즉시 수행되게 된다. 만일 당신이 이 옵션을 선택하면, 허드슨은 모든 빌드 후속 업무들의 테스트 결과들을 모으고, 소급 적용하는 식으로 해당 내용들을 주요 빌드 업무에 대한 테스트 결과로 보고할 것이다.
  • 다른 프로젝트 빌드하기(Build other projects): 앞선 항목들과 관련되어서, 이 옵션은 하나의 논리적인 빌드와 테스트 프로세스를 연속적으로 수행되어야 하는 두 개 이상의 물리적인 업무로 구현하기 위해 사용된다. 이 옵션을 선택되면, 필드가 보여지게 될텐데, 이 필드에는 현재 업무 이후에 수행되길 원하는 업무 이름들을 콤마(,)로 분리해서 기입하면 된다. 이 작업은 비록 현재 현재 업무 수행이 빌드가 불안정하다고 판단할 지라도 선택한 내용에 따라 수행된다.
  • 이메일 공지(E-mail notification): 이 옵션을 선택하면, 하나 혹은 그 이상의 공백으로 분리된 이메일 주소를 입력할 수 있고, 해당 이메일로 허드슨의 업무 수행 완료 공지가 보내지게 된다. 빌드 실패, 불안정 빌드 등의 이벤트들은 이메일 발송을 일으키게 된다. 여기에 있는 추가적인 옵션은 허드슨이 판단하기에 빌드를 깨뜨린 코드를 SCM에 체크인 한 작업자에게 "특별한" 이메일을 보내도록 만드는 것이다.


  • 출처 및 참고 사이트 
    http://wiki.hudson-ci.org/display/HUDSON/Home
    http://bcho.tistory.com/entry/Hudson을-이용한-빌드-배포-테스트-자동화
    http://doortts.tistory.com/entry/번역-허드슨을-이용한-지속적인-통합Continuous-integration-with-Hudson-2