통합빌드를 수행하기 위해 전체 소스를 SCM(소스저장소)에서 취합하는 방식은 2가지로 나뉜다.

1. 체크아웃 방식
-매번 새로 전체 소스를 SCM으로부터 체크아웃 받음
-소스의 양이 많을 경우 내려받는 시간이 오래걸림
-항상 깨끗한 상태의 소스를 이용하므로 스테이징/운영 서버에 배포하기 위한 용도에 적합

2. 업데이트 방식
-처음 한번만 전체 소스를 체크아웃 받고 그 이후로는 변경된 소스만 SCM으로부터 업데이트 받음
-변경된 소스만 받아오므로 상대적으로 시간이 덜 걸림
-순전히 빌드오류를 잡아내어 피드백을 주기 위한 빌드에 적합(?)


* 위 2가지는 다시 무조건 최신 소스를 가져오느냐 아니면 특정 버전(태그)의 소스만 가져오느냐로 나뉠 수 있다.
* Hudson에서는 빌드Job 선택 > Configure > Source Code Management > Advanced… > ‘Use Update’ 옵션 체크시 2번의 업데이트 방식이 적용된다.

* 조대협님 블로그 참조함

신고
크리에이티브 커먼즈 라이선스
Creative Commons License
Posted by 에코지오

댓글을 달아 주세요

우리는 빌드,테스트,배포를 자동화하기 위해 Ant나 Maven 같은 걸로 작업을 정의한 스크립트를 만듭니다.
스크립트가 완성되면 이제 스크립트를 실행할 일만 남았습니다. 그럼 이 스크립트를 언제, 어떻게 실행할까요?
자동화 프로세스를 런치시키는 3가지 유형이 있습니다

1. 예약 자동화(scheduled)
-일정 주기마다 자동으로 작업 실행
-개발자들의 스케줄관리에 유리하며 대규모 빌드에 적당
-오랜 시간 소스에 변경이 없을 경우 불필요한 빌드 발생

2. 유발 자동화(triggered)
-이벤트 발생시 자동으로 실행
-이벤트 감지를 위한 폴링 간격이 짧고 커밋이 자주 발생하는 경우 빌드적체 유발 가능성 있음

3. 지시 자동화(commanded)
-커맨드라인에서 빌드스크립트를 직접 실행하거나 빌드서버에서 빌드버튼을 클릭하는 등의 방법으로 사용자가 수동으로 작업을 실행
-비정기적인 빌드/배포를 수행해야 할 경우 사용


* 조대협님 블로그와 실용주의 자동화 책 참고

신고
크리에이티브 커먼즈 라이선스
Creative Commons License
Posted by 에코지오

댓글을 달아 주세요

지금 몸담고 있는 회사의 빌드관련 문서에는 build와 deploy를 이렇게 정의하고 있다.

- build : 소스를 실행가능한 모듈로 변환하는 것
- deploy : 빌드되어 실행가능한 결과물을 컨테이너에서 인식가능한 곳에 배치하는 것

build는 별로 어렵지 않지만 deploy는 곰곰이 생각할 것이 많다. 내용상으로는 install과 비슷하고, 번역용어가 distribution과도 헷갈린다.

실행가능한 모듈을 실행 가능한 곳에 위치시키고 설정하는 것. install 아닌가?  그러나 OS위에서 작동하는 소프트웨어에 대해서는 대개 install이라 하고, WAS같은 컨테이너에서 작동하는 어플리케이션이나 재사용 레포지토리에 저장되는 서비스모듈에 대해서는 deploy라고 구별하는 것 같다 (이게 소프트웨어와 어플리케이션/라이브러리의 차이에서 오는 개념구분인지도 모르겠다).

deploy 및 관련된 deployables, distribution의 개념에 대해 개인적으로 다시 정리해보았다.

* deployables(deployable application)
- 정의 : WAS같은 컨테이너 상에서 실행가능한 어플리케이션.
- 설명 : 자바 환경이라면 war,ear,jar 같은 것들을 말한다. deployables는 소프트웨어 distribution의 한가지 형태라고 봐도 될듯하다. 근데 이걸 뭘로 번역할지는? 배포물? 배포가능 어플리케이션?

* deploy (deployment)
- 정의 : deployables를 실제 컨테이너에 배치(arrange? allocate?)하는 작업. 
- 설명 : 간단히 말하면 어플리케이션을 WAS 상에 설치(install)하는 것이다. deploy는 전개,배치,배포 등으로 다양하게 번역되며 보통 디플로이 또는 배포라고 부른다. 그러나 배포라는 표현은 distribution과 혼동을 일으키기 쉽기 때문에 개인적인 의견으로는 배치가 더 맞는 표현이 아닐까 생각하지만, 역시나 배치라고 불렀을 때 batch와 발음이 같아서 또다른 혼동을 일으킬 수 있다.

* distribution
- 정의: 누군가에게 전달(delivery)하기 위해 패키징된 소프트웨어. (또는 그것을 전달하는 행위)
- 설명 : 사전적으로는 분배,배분,배포의 의미를 가지며 보통 배포본, 배포판으로 번역한다.

ps1. IBM 프로젝트 자동화 아티클에서는 deployment를 전개로, distribution을 배포로 번역했다. 헷갈리게시리...-.-;

ps2. 위의 deploy 정의는 웹어플리케이션 개발 영역에서나 통하는 정의이고 이전에 언급했듯이 메이븐에서는 아티팩트를 저장소에 올리는 걸 deploy라고 부른다. 그래서 메이븐 처음 접하면서 오해하게 되는 게, 메이븐이 웹어플리케이션을 WAS에 배포하는 것까지 간단하게 해준다고 생각한다. 천만에 만만에 콩떡인거다.

ps3. 소스를 컴파일/빌드하여 생긴 결과물을 뭐라고 부르는게 좋을까?
빌드결과물? 빌드산출물? 배포본? 에셋? 바이너리? 실행파일번들? 빌드모듈?
개인적으로는 빌드산출물이 맘에 든다.

ps3. deployables. 이건 deployable thing을 표현한 단어인데, cargo에서 아이디어를 따왔다. 실제 이런 단어가 있는건 아닌거 같다.
신고
크리에이티브 커먼즈 라이선스
Creative Commons License
Posted by 에코지오

댓글을 달아 주세요

  1. BlogIcon 에코지오 2008.11.15 08:06 신고  댓글주소  수정/삭제  댓글쓰기

    http://softwaredev.tistory.com/entry/빌드와-컴파일의-차이

  2. BlogIcon 에코지오 2009.10.07 10:55 신고  댓글주소  수정/삭제  댓글쓰기

    빌드결과물 : 실행파일도 좋은듯.

Hudson을 이용한다면 scm 저장소로부터 (메이븐 타입의) 프로젝트를 체크아웃/업데이트 받아서 특정 goal/phase를 실행하는 일은 Hudson의 몫이다. 그러니까 보통은 메이븐타입 프로젝트의 pom.xml로는 프로젝트 자체를 scm에서 체크아웃/업데이트 받는 일은 안한다.

하지만 허드슨을 이용하지 않고 허드슨의 일을 대신해서 프로젝트 소스를 scm으로부터 받아와서 빌드/배포 goal을 실행해야 하는 상황이라면 어떻게 해야할까?

scm에서 체크아웃/업데이트하고 프로젝트 안의 pom.xml에 대해 goal을 실행하는 쉘스크립트를 짜는 것도 한가지 방법일 수 있지만 이러한 작업을 하는 또다른 pom.xml을 만드는 것도 가능하다. maven-scm-plugin 플러그인을 이용하면 된다.

 <scm>
  <connection>scm:svn:https://127.0.0.1:8443/svn/XXX</connection>
 </scm>
 ... ...
<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-scm-plugin</artifactId>
    <version>1.1</version>
    <configuration>
     <connectionType>connection</connectionType>
     <scmVersionType>tag</scmVersionType>
     <scmVersion>${scm.version}</scmVersion>
     <checkoutDirectory>workspace</checkoutDirectory>
     <workingDirectory>workspace</workingDirectory>
     <skipCheckoutIfExists>true</skipCheckoutIfExists>
     <username>user</username>
     <password>user</password>
     <goals>clean test war:inplace</goals>
     <profiles>env-staging</profiles>
    </configuration>
 </plugin>

위처럼 pom.xml을 만들어 놓고 scm:bootstrap 을 실행하면 메이븐은 checkoutDirectory로 지정된 workspace에 프로젝트 소스를 체크아웃 받는다. 체크아웃 받은 뒤에 프로젝트 root의 pom.xml에 대해서 <goals/>에 나열된 goal을 실행해준다.

mvn -Dscm.version=RB123 scm:bootstrap
신고
크리에이티브 커먼즈 라이선스
Creative Commons License
Posted by 에코지오

댓글을 달아 주세요

단위 테스트케이스 소스가 없는 프로젝트를 메이븐으로 빌드할 때 test phase(단계)는 불필요한 것이 명백하다.

  <plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-surefire-plugin</artifactId>
    <configuration>
      <skip>true</skip>
    </configuration>
  </plugin>

또는 maven.test.skip 프로퍼티 값을 true로 설정하면 test phase에 바인딩된 surefire:test 골의 실행을 skip할 수 있다.

메이븐에서 deploy는 개발 결과 아티팩트(jar,war,....)를 리모트의 메이븐 저장소에 등록하는 것을 의미한다.
공통라이브러리나 오픈소스 라이브러리를 개발한다면 이게 deploy의 의미에 합당할지도 모르겠다.
그러나 아마도 대부분의 JEE 기반 웹시스템 개발 프로젝트에서 deploy는 웹어플리케이션을 WAS에 배치하는 것을 의미한다. test 단계를 skip한 것처럼 deploy 단계에 기본으로 바인딩된 deploy:deploy 골도 skip할 수 있다.

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-deploy-plugin</artifactId>
    <configuration>
     <skip>true</skip>
    </configuration>
</plugin>

이렇게 deploy:deploy를 skip해놓고 anttrun 등으로 WAS에 배포본을 올리는 작업을 deploy phase에 바인딩하면 deploy가 진정 내가 원하는 deploy로 바뀌게 된다.

한가지 또 아쉬운게 있다면 deploy 단계 이전에 실행되는 install 단계도 skip할 수 있으면 좋겠는데 안타깝게도 install:install 모조에는 skip 옵션이 없다. 젠장.
신고
크리에이티브 커먼즈 라이선스
Creative Commons License
Posted by 에코지오

댓글을 달아 주세요



티스토리 툴바