Continuous Integration 변경될때마다소프트웨어를빌드하기pds16.egloos.com/pds/201002/17/18/3.Continuous_Build.pdf테스트성능을개선하기 자동화된빌드를여러범주로나누고다른시간대에테스트실행

Continuous Integration

변경될 때마다 소프트웨어를 빌드하기

조영호

카페PJT팀

2008.09.08

[email protected]

1. 빌드 자동화

2. Maven

목차

3. 빌드 유형과 메커니즘

4. 빌드 시간을 짧게 만들기

1. 빌드 자동화

4 / 문서의 제목

빌드 자동화

소프트웨어의 개발은 복잡할지 몰라도 소프트웨어의 전달

(Delivery)은 버튼 하나만 누르면 되는 일이 되어야 합니다


빌드 프로세스

빌드 스크립트

벤더 라이브러리

제품 코드

문서

테스트 코드

문서

스크립트/실행파일

사용자 정의라이브러리

벤더 라이브러리

빌드 프로세스


자동화된 통합 빌드

피드백주기

소프트웨어품질을향상시키고위험을줄이기

| \ \

}]

{[

“‘ Integrate

?/

shift?/

P ㅖㅔ

통합하기

소스 코드컴파일하기

테스트돌리기

검사수행하기

소프트웨어배포하기

데이터베이스통합하기


파삭파삭(CRISP)한 빌드

완전한Complete

반복가능한Repeatable

정보를주는Informative

• 빌드 조리법에 지정된 재료만으로 빌드 가능

• 자급자족하는 빌드

예약가능한Schedulable

이식가능한Portable

• 빌드 파일과 빌드 입력을 버전 관리 저장소에 보관

• 예전 릴리즈를 쉽게 재생성

• 소프트웨어의 상태를 알 수 있는 정보 제공

• 피드백 메커니즘

• 완전(Complete)하고 반복 가능(Repeatable)한 빌드는 예약 가능

• 특정 시간, 일정한 시간 간격, 이벤트 발생 시

• 어디에서도 소프트웨어 빌드가 가능

• 빌드가 특정 IDE, 기기의 IP 주소, 실행 디렉토리에 독립


빌드 스크립트를 구성하는 프로세스

빌드 스크립트

정리(Clean) 하기

소스 코드 컴파일하기

데이터베이스 통합하기

테스트 돌리기

검사 돌리기

소프트웨어 배포하기

| \ \

}]

{[

“‘ Integrate

?/

shift?/

P ㅖㅔ


명령어 하나로 빌드를 수행하기

IDE에 독립된 빌드

빌드에 필요한 모든 재료를 버전 관리 저장소에 저장

수많은 도구 중에 어느 걸 골라서 사용할

것이냐가 중요한 것이 아니라, 손수 솔루션

을 만들지 않고 만들어져 있는 빌드 도구를

잘 사용하는 것이 중요합니다.


빌드 스크립트를 IDE에서 떼어내기

빌드 스크립트

의존의존

개발자마다 IDE의 차이 문제를 해결하기 어려울 수도 있기 때문

CI를 통한 자동화 빌드를 실행시키기 위해

NO


빌드 스크립트를 IDE에서 떼어내기

개발자마다 IDE의 차이 문제를 해결하기 어려울 수도 있기 때문

CI를 통한 자동화 빌드를 실행시키기 위해

빌드 스크립트

의존의존

OK


소프트웨어 자산을 중앙 집중화하기

버전 관리 저장소에 모든 파일을 보관

소스 파일이나 라이브러리 파일과 같은 컴포넌트

JAR, 라이브러리, DLL과 같은 외부 컴포넌트

설정 파일

어플리케이션 초기화 데이터 파일

빌드 스크립트와 빌드 환경 설정

일부 컴포넌트를 설치하는 스크립트

‚하지만 내 컴퓨터에서는 잘 되는데요‛


빌드를 빨리 실패하게 만들기

실패하는 법을 아는 빌드가 좋은 빌드

실패할 가능성이 높을 수록 먼저 실행

빨리 실패할 수록 실행 시간 감소

실패 원인을 찾기 위한 시간 감소

Feedback


어떤 환경에서라도 빌드하기

다양한 환경에 맞는 설정 파일들을 저장소에 보관

로깅 정도

어플리케이션 서버 정보

데이터베이스 연결 정보

프레임워크 설정

빌드 스크립트 매개변수 사용

mvn –P junit_alpha clean install war:inplace

설정 파일 사용

빌드 스크립트 local.properties integration.properties qa.properties production. Properties


전용 통합 빌드 머신 사용하기

지속적인 통합 서버

통합 빌드 머신

빌드를 함께 할 사람 구함

저는 단일 프로세서를 가진, 조금 오래된 컴퓨터인데, 변화를 수용할 수 있고,

데이터를 꾸준히 제공할 수 있는 사람과 오랜 관계를 맺고 싶습니다. 버전 관

리 시스템 저장소에 접근할 수 있기 때문에 친구들은 제가 아주 능력 있다고

합니다. 거만한 노트북들과는 달리 저는 하루 종일 사무실에 대기하는 것을

즐깁니다. 제가 마지막으로 재부팅된 것은 7일하고도 더 전이었습니다. 게다

가 곧바로 회복되었습니다. 당신을 직접 만나길 기대합니다. 아니면 저의 수

많은 원격 인터페이스를 통해 채팅할 수도 있을 겁니다.

환경과 설정에 대한 가정 감소

‚내 컴퓨터에선 작동하는데요‛ 문제 방지


2. Maven


Maven

Convention over Configuration

not ‘How’ but ‘What’


Ant와 Maven

DEMO

not ‘How’ but ‘What’

Declarative Execution – POM Model


Super POM

Convention over Configuration

Every POM Inherits Super POM

http://maven.apache.org/guides/introduction/introduction-to-the-pom.html









기본 디렉토리 레이아웃

target/

src/

pom.xml

project/

main/

java/

test/

java/

classes/

test-classes/

Surefire-reports/

Convention

over

Configuration


의존성 관리

<dependencies>

<dependency>

<groupId>junit</groupId>

<artifactId>junit</artifactId>

<version>4.2</version>

</dependency>

</dependencies>

pom.xml

라이브러리를 어디에서 찾는가?

라이브러리는 어디에 위치하는가?


Repository

Remote Repository

다양한 프로토콜(file://, http://...) 을 사용하여 접속

중앙 저장소는 http://repo1.maven.org

http://mvnrepository.com을 통해 쉽게 검색 가능

Local Repository

다운로드 받은 artifact와 최신 빌드 artifact 캐시

${user.home}/.m2/repository

http://repo1.maven.org/

http://mvnrepository.com/


Phase and Goal

Build Lifecycle은 Phase의 집합

Phase들은 정해진 순서에 따라 순차적으로 실행

Phase는 하나 이상의 Goal 수행 compile

test

package

install

deploy

clean


SiteDefaultClean

Phase

pre-clean

clean

post-clean

validate

generate-sources

process-sources

generate-resources

process-resources

compile

process-classes

generate-test-sources

process-test-sources

generate-test-resources

process-test-resources

test-compile

test

prepare-packaging

package

pre-integration-test

integration-test

post-integration-test

verify

install

deploy

pre-site

Site

post-site

site-deploy


Phase and Plugin

Phase는 작업을 완료하기 위해 연관된 Plugin 호출

pom.xml

archetype

compiler

surefire

jar

install

generate-sources

compile

test-compile

test

package

integration-test

install

deploy

PluginsLifecycle Phases

| \

\

}]

{[

“

‘In t egrate

?

/

sh if t?/

P

ㅖ

ㅔ

mvn compile

mvn test

mvn install


Phase, Plugin, and Goal

Plugin은 공통 목표를 가진 Goal들의 집합

Goal은 하나의 태스크

하나 이상의 Phase에 바인딩

Phase에 바인딩되지 않은 Goal은 Maven 실행 시 독립적으로 실행 가능

Plugin

Phase goal

goal

goal

Plugin

Phase 실행시자동실행

Maven 실행시파라미터로명시

mvn clean package cobertura:cobertura


Maven Plugins

Maven은 빌드 생명 주기 내에서 Plugin을 실행하는 플랫폼

Phase Mojo Plugins

process-resources resource maven-resources-plugin

compile compile maven-compiler-plugin

process-test-resources testresources maven-resources-plugin

test-compile testcompile maven-compiler-plpugin

test test maven-surefire-plugin

package jar maven-jar-plugin

install install maven-install-plugin

deploy deploy maven-deploy-plugin


Packaging 형태에 따른 Phase-Goal 매핑

process-resources resouces:resources

compile compiler:compile

process-test-resources resources:testResource

test-compile compier:testCompile

test surefire:test

package jar:jar or war:war etc...

install install:install

deploy deploy:deploy

ejb, ejb3, jar, par, rar, war

Packaging 형태에 따른 Default Lifecycle Binding

CleanLifecycle Binding clean clean:clean

mvn clean package


Packaging 형태에 따른 Phase-Goal 매핑

eargenerate-resources ear:generateApplicationXml

process-resources resources:resources

package ear:ear

install install:install

deploy deply:deploy

pom package site:attach-descriptor

process-resources resources:resources

deploy deploy:deploy

Packaging 형태에 따른 Default Lifecycle Binding


Plugin을 통한 Plugin-Goal 실행

pom.xml에 plugin 추가 후 Maven 실행 시 파라미터로 plugin:goal 명시

<plugin>

<groupId>org.codehaus.mojo</groupId>

<artifactId>cobertura-maven-plugin</artifactId>

<version>2.2</version>

<configuration>

<formats>

<format>xml</format>

<format>html</format>

</formats>

<instrumentation>

<excludes>

<exclude>**/*UnitTestSuite.class</exclude>

</excludes>

</instrumentation>

</configuration>

</plugin>

pom.xml

mvn cobertura:cobertura


실행 순서는?

mvn clean package cobertura:cobertura

jar packaging

3. 빌드 유형과 메커니즘


빌드 유형

개인 빌드Private Build

통합 빌드Integration Build

릴리즈 빌드Release Build


빌드 유형




• 개발자 빌드

• 소스 코드 커밋 전 실행

• 버전 관리 저장소의 최신 변경사항과 수정한 코드 통합

개발자

빌드 스크립트

버전 관리 저장소

1 저장소에서 코드를 체크아웃한다

2 소스 코드를 변경한다

4 로컬에서 ‘통합 빌드’를 돌린다

3 저장소에서 변경 사항을 가져온다

5 코드를 저장소에 커밋한다


빌드 유형




• 팀이 저장소에 커밋한 변경사항과 주흐름 통합

• 별도의 전용 컴퓨터에서 실행

• Commit Build

10분 이내의 가장 빠른 통합 빌드

컴파일과 단위 테스트

• Secondary Build

속도가 느린 컴포넌트, 시스템, 성능 테스트 포함

코딩 표준 준수, 코드 복잡도 검사와 같은 자동화된 검사 포함


빌드 유형


• 사용자에게 출시할 제품 준비

• 한 주기나 이정표milestone 끝 무렵 실행

• 더 많은 성능 및 부하 테스트 포함

• 인수 테스트는 반드시 포함

• 사용자의 환경에서 실행 가능한 설치 매체 생성

• 품질 보증 팀이 사용하는 것도 가능




빌드 메커니즘

지시자동화(Command Automation)

예약자동화(Scheduled Automation)

유발자동화(Triggered Automation)


빌드 메커니즘

주문형지시자동화

(Command Automation)

예약자동화(Scheduled Automation)



빌드 메커니즘



일정기반, 변경사항폴링예약자동화

(Scheduled Automation)



빌드 메커니즘



일정기반, 변경사항폴링예약자동화

(Scheduled Automation)

이벤트주도유발자동화

(Triggered Automation)


주문형개인 빌드Private Build



빌드 유형에 따른 메커니즘





일정기반주문형 변경사항폴링

이벤트주도






주문형 일정기반

일정기반주문형 변경사항폴링

이벤트주도


4. 빌드 시간을 짧게 만들기


통합 빌드 지속 시간 개선 방안

개선방 안전술 우선순위 확장성 성능 난이도

전용통합빌드머신사용하기 1

통합빌드머신의하드웨어사양늘리기 2

테스트성능을개선하기 3

통합빌드를효율적으로만들기 4

하부구조를최적화하기 5

빌드프로세스를최적화하기 6

시스템컴포넌트를따로빌드하기 7

소프트웨어검사성능을개선하기 8

분산된통합빌드를수행하기 9

확장성, 성능, 난이도에 미치는 영향

높음 중간 낮음


테스트 성능을 개선하기

자동화된 빌드를 여러 범주로 나누고 다른 시간대에 테스트 실행

단위, 컴포넌트, 시스템 테스트

테스트 리팩토링

Mock/Stub 사용

단위 테스트 환경에서 사용하기 복잡한 컴포넌트일 경우

오래 걸리는 통합 테스트를 별도의 테스트 스윗으로 분리

병렬로 테스트 실행

빌드 유형에 따라 테스트를 나누어서 실행

커밋 빌드, 2차 빌드, 전체 통합 빌드, 릴리즈 빌드

네트워크 케이블을 빼고 데이터베이스를 종료시키고 나서도 돌아

가는 테스트가 진짜 단위 테스트입니다


빌드를 여러 단계로 나누기

개발자

서브버전

개발자

개발자

피드백 메커니즘

빌드 스크립트


통합 빌드 머신버전 관리 저장소

변경 사항커밋하기 폴링

소스 코드 컴파일 하기,데이터베이스 통합하기,테스트 돌리기,검사 돌리기,소프트웨어 배포하기

피드백 생성하기피드백


개발자

서브버전

개발자

개발자





피드백생성하기

피드백


소스 코드 컴파일 하기,데이터베이스 통합하기,

테스트 돌리기,검사 돌리기,


Commit Build

(가벼운 빌드)


개발자

서브버전

개발자

개발자






피드백


더 오래 걸리는 테스트(컴포넌트, 시스템, 기능, 성능),

코드 적용 범위

Commit Build가

성공하면

Secondary Build

(무거운 빌드)

Commit Build

(가벼운 빌드)





개발자

서브버전

개발자

개발자






피드백


더 오래 걸리는 테스트(컴포넌트, 시스템, 기능, 성능),

코드 적용 범위

Commit Build가

성공하면

Secondary Build

(무거운 빌드)

기벼운 빌드를 먼저 실행시키고 무거운 빌드를 나중에 실행

빌드 시간 단축

Commit Build

(가벼운 빌드)





시스템 컴포넌트를 따로 빌드하기

소프트웨어를 더 작은 하위 시스템으로 분리

개별적인 하위 시스템을 따로 빌드

하위 시스템을 별도의 프로젝트로 구성

하위 시스템 중 하나를 마스터 프로젝트로 설정

빌드 의존성을 설정

마스터 프로젝트 변경 시 다른 프로젝트 자동 빌드

Thank you.

Question.

Documents

Continuous Integration 변경될때마다소프트웨어를빌드하기pds16.egloos.com/pds/201002/17/18/3.Continuous_Build.pdf테스트성능을개선하기 자동화된빌드를여러범주로나누고다른시간대에테스트실행