허드슨을 이용한 지속적 통합 (Continuous Integration)

Using Hudson / Jenkins

“Continuous Integration”

2013.11.18
장윤기 (yoonki.chang@gmail.com)

목차

1. 지속적 통합 이해하기
2. 스스로 적용하기
3. 다른 사람들의 활용 방식
4. 질의 응답

2 | Copyright 2013. Created by Yoonki Chang (yoonki.chang@gmail.com)

1

지속적 통합 이해하기
1.1 왜 소프트웨어 프로젝트는 실패하나요?
1.2 실패를 줄일 수 있나요?

1.3 또 배워야 하나요?
1.4 무엇부터 어떻게 시작할까요?
1.5 최종 목표는 무엇인가요?

1.1 왜 소프트웨어 프로젝트는 실패하나요?
• 소프트웨어 산업과 다른 산업과의 차이점
i. Software Is
Complex

ii. Software Is
Abstract

iii. Requirements
Are Incomplete

ix. Repetitive
Work Is
Automated

iv. Technology
Changes Rapidly

v. Best Practices
Are Not Mature

vi. Technology Is
a Vast Domain

vii. Technology
Experience Is
Incomplete

viii. Software
Development Is
Research

x. Construction Is
Actually Design

xi. Change Is
Considered Easy

xii. Change Is
Inevitable
* 출처 : Software Project Secrets. Why Software Projects Fail. Apress 2005


• XP는 개발 본연의 임무를 강조한 Agile 방법론임

12 Practices of eXtreme Programming

주요 개선 활동
The Planning Game
Testing
Pair Programming
Refactoring
Simple design
Collective code ownership
Continuous integration
On-site customer
Small release
40-hour week
Coding standard
System metaphor


활용 도구
포스트잇
개발툴
(Eclipse/Jdeveloper ...)

형상관리
문서 저작 도구
CI 도구

<<인식 전환>>

• 위험을 줄여준다.
• 특정 소스 코드의 컴파일 오류로 전체 소프트웨어 컴파일이 되지 않는 문
제를 빠르게 대처할 수 있음

• 반복적인 수작업을 줄여준다
• 개발자의 반복적이고 지루한 작업을 자동화하여 개발자는 개발에만 집중
할 수 있도록 함
• 코드의 변경에 대해 자동적으로 단위 테스트 및 영향 분석을 레포팅하고
이를 통해 소프트웨어의 품질을 향상 시킬 수 있음

• 언제 어느 때라도 배포할 수 있는 소프트웨어를 생성해낸다
• 빌드와 배포를 반복적으로 수행함으로 소프트웨어를 테스트할 수 있는
기회를 더욱 높일 수 있으며 이로인해 소프트웨어 품질이 높아짐
• 문제 상황 발생시 이를 빠르게 피드백 받고 즉각 처리할 수 있는 환경을
마련함

• 프로젝트 가시성을 좋게 한다
• 소프트웨어 제품에 대해 보다 큰 자신감을 갖게 해준다.

1.3 또 배워야 하나요?
• 우리가 하는 일을 줄여줄 수 있다면 도구를 배우는 것을 두려워
해서는 안됨
도보 이동

• 소요시간 : 28분
• 총거리 : 1.8 km


대중교통 이동

• 총거리 : 2.0 km

자가용 이동

• 총거리 : 1.8 km

1.4 무엇부터 어떻게 시작할까요?
• 어렵게 생각하지 말고 쉽게 본인이 필요하다고 생각되는 영역
부터 하나 하나 적용해 보는 것이 좋음
• CI 도구를 개발자를 통제하기 위한 도구로 생각해서는 안되며
생산성 향상을 위한 도구로 사용해야 함
개발자 측면

관리자 측면

스스로 해야 할 것
1. 쉬운 CI 도구 선정
2. 빌드 자동화 (형상관리 + ANT / MAVEN)
3. 배포 자동화 (TOMCAT, FTP 등)
4. 테스트 자동화 (Junit 등)
5. 소스 코드 품질 검사 자동화 (PMD 등)

스스로 해야 할 것
1. 인내력을 가지고 기다림
2. CI는 생산성 향상 도구 (통제 도구 아님)
3. CI를 위해 투자하는 시간, 돈
4. 고성능 하드웨어 장비를 지급하는 여유

요구해야 할 것
1. CI 적용을 위한 시간 확보
2. 배우기 위한 자료 (책, 교육 등)
3. 형상 관리, CI 도구 등을 위한 장비 확보


요구해야 할 것
1. 개발자 인식 전환
2. 단순 반복 작업이 아닌 생산적인 작업에
시간을 투자
3. 가치를 높이기 위한 노력

1.5 최종 목표는 무엇인가요?
• CI 도구는 최초 고려된 목적 외에 다양한 형태로 확대되고 있음
• CI 도구를 적용할 때에는 목표와 목적을 정확히 하고 로드맵에
따라 순차적으로 적용해갈 필요가 있음
‘나’를 위한 자동화
인식 전환 및 기초환경 마련

환경 마련

통합 관리 체계 확보

1. 개발 생산성 향상에 대한
고민

5. 모든 소스 코드 관리는 형상
관리로 이관

8.개발에서 배포까지 자동화
환경 마련

2. XP 방법론에 따른 CI 도구
적용 고려

6. CI 도구 설치 및 사용 환경
마련

9. 단계별 레포트 자동화

3. CI 도구를 통해 얻고자 하는
목표 수립

7. CI 도구를 이용한 빌드 및
검사, 테스트 자동화 환경
마련

4. 개발 프로세스에 CI 도구
사용에 대한 방안 마련


10.전체 개발 영역으로의 확대

2

스스로 적용하기
2.1 CI 사용을 위한 PATH
2.2 CI 도구 선택하기

2.3 형상관리 중심으로 작업하기
2.4 빌드 자동화 하기
2.5 배포 자동화 하기
2.6 테스팅 자동화 하기

2.7 레포팅 및 피드백
2.8 더욱 발전을 위해서

2.1 CI 사용을 위한 PATH
• CI를 활용하고자 하는 PATH를 작성하고 해당 PATH에 따라 어
떠한 적용을 할지 고려할 필요 있음
Planning
시작

적용 목표 수립

적용 단계 수립

적용 방안 마련

CI 도구 선택

Iteration
CI 설치

CI 작업 정의

최신 코드
업데이트

단위 테스트
개발 (Junit)

App 개발

소스코드 커밋

배포 연동

종료

기능 테스트
연동

품질 검사
연동

레포팅

형상관리 설치

빌드 연동

결과 피드백

• 한번 선택한 CI 도구를 나중에 변경하기 위해서는 많은 시간과
노력이 필요하므로 도구 선택 작업은 CI 시작을 위한 매우 중요
한 단계임
• 일반적인 경우 Free Software인 Jenkins / Hudson으로도 충분
히 커버가 가능함
• Free Software
• 무료 혹은 특정 조건하에 비용 지불 없이 사용할 수 있는 소프트웨어
• Jenkins / Hudson을 일반적으로 사용함. 특정 목적을 위해 커스텀 개발이
필요할 수 있음

• Commercial Software
• 상용 제품으로 대부분 가격이 상당히 고가임
• 기능적으로 관리적으로 많은 장점을 가지고 있음
• Jetbrains TeamCity, Atlanssian Bamboo, IBM Build Forge, MS Team
Build 등이 유명

• CI 도구를 선정시 고려해야 할 평가 기준
평가 요소
형상 관리 연계

설명
•
•

CVS, Subversion, IBM ClearCase, Serena Dimension, CA Harvest, Borland StarTeam 등과의
연동 기능
형상 관리 서버의 변경을 감지하고 이를 지속적 통합 작업과 연계할 수 있는 기능

빌드 도구 연계

•
•
•

현존하는 빌드 도구 혹은 빌드 스크립트와 연동할 수 있는 기능
ANT, MAVEN, NAnt, MSBuild 그리고 make 같은 도구와 연동할 수 있는 기능
유닉스 쉘 스크립트나 윈도우 배치 커맨드와 연동할 수 있는 기능

테스트 도구 연계

•
•

xUnit 계열의 단위 테스트 도구와 연동 기능
TQM을 목표로 하는 대단위 테스트 도구들과의 연동성 (예, HP QTP)

검사 도구 통합

•

코드에 대한 검사, 보안에 대한 검사, SQL 검사를 위한 도구와의 연계 기능

•
•

지속적 통합 서버가 연동하는 형상 관리, 빌드 도구, 테스트 도구, 검사 도구 등과 연동하여
해당 수행 결과를 확인할 수 있는 기능
확인된 수행 결과를 적합한 사람들에게 이메일, SMS, 메신져 등으로 피드백 하는 기능

분산 시스템

•
•

분산 환경 지원하는 기능. 메인 서버와 슬레이브 서버를 설정할 수 있는 기능
특정한 운영체제와 하드웨어에 제한 없이 윈도우, 유닉스, 리눅스 등을 지원

통합 절차의 다양성

•
•

지속적 통합 절차를 정의하기 위한 다양한 방법을 제공
작업에 대한 스케쥴링 기능과 형상 관리 변경을 통한 작업 실행 기능을 제공

권한 관리

•

개발자 혹은 관리자에 따른 권한 관리 기능.

진행 사항 모니터링

•

지속적 통합 도구의 상태를 실시간으로 확인할 수 있는 기능. 통합 Dashboard

확장 가능성

•

기본 제공 기능 외에 특정한 목적으로 확장 및 변경 가능한 기능

피드백 및 레포팅

* 출처 : 허드슨을 이용한 지속적 통합. 인사이트. 2012


2.3 형상 관리 중심으로 작업하기
• 소스 코드에 대한 형상 관리를 적용할 경우 여러 가지 주의해야
할 항목들이 존재
– 개인이 만들어내는 소스 코드는 결코 개인의 사유 자산이 아니다. 모든
소스 코드는 공유를 기본 원칙으로 한다.
– 형상 관리에 소스 코드를 커밋한다는 의미는 해당 소스 코드에 결함이 없
고 실행이 가능함을 의미한다.
– 형상 관리 서버는 개인의 자료 백업 서버가 아니다.
– 보안등의 이유로 공유가 제약되는 경우라도 제약을 최소화 할 수 있는 방
향으로 정책을 마련한다.

지난번에 계산 알고
리즘 소스 코드 좀
공유해 줄래?

그거 소스 코드 나
없는데…

얼마나 고생한건데
내가 널 주냐…

2.3 형상 관리 중심으로 작업하기
• 모든 CI 활동의 중심에는 모든 소스 코드는 형상 관리 서버에
의해서 관리되고 있다는 전제를 가지고 있음
• 형상관리 커밋 단위로 CI 자동 실행하도록 설정
• 주기적으로 형상관리에서 체크아웃 후 레포팅 하도록 설정
형상 관리 서버

허드슨 서버
허드슨 작업

전처리

개발자

갱신

저장소 반영

작업공간

커밋 요청

후처리

저장


저장소

작업
호출

• 컴파일은 가장 기초적이며 가장 확실한 1단계 버그 FIX 도구
• 프로그램이 클수록 빌드 오류의 확률이 높아지며 이를 지속적
으로 확인해야 함
– 통합 개발 도구의 자동 빌드 기능을 OFF 해 놓는 경우: PC에서 빌드에 계
속 성공하고 있다고 착각하게 되는 경우가 있다.
– 프로젝트 표준 빌드를 자기 자신만의 방식으로 변경해서 사용한다.
– 정상적인 모든 소스 코드를 커밋하지 않는 경우이다.
– 하나의 소스 코드에 여러 명이 동시에 개발하는 경우 오류에 대한 책임을
서로 미루게 되며 영원히 해결되지 않는 컴파일 에러 상황에 도달할 수
있다.
제 PC에서는 컴파일 잘되는데요.
서버 문제 아니에요?


• 빌드는 이클립스와 같은 개발도구에 의해서 자동화 해주고 있
으나 모든 환경 (특히 서버 환경)에서 이클립스를 사용할 수 있
을 거라는 기대를 해서는 안됨
• 대부분의 CI 도구는 빌드 기능을 제공하지 않음
빌드 요청

1

배포 서버
Hudson Master

8

대상 서버
Hudson Slave

9

2
빌드 서버

Deploy Script

Deploy Agent

DEPLOY

3
Deploy Script
CHECKOUT

5
COMPILE

6
PACKAGING

7
SEND


4

형상 관리 서버

• 배포는 소프트웨어를 서비스하기 위한 가장 중요한 단계이며
서비스 하기 이전 개발자/설계자/관리자/고객에 의한 테스트를
위한 중요 항목임
개발한 프로그램을 운영 데이터로 테
스트하게 서버로 배포 좀 해주세요

우리 프로젝트는 배포는 밤 12시에 한
번만 한다. 밤 12시 이후에 테스트하던
지 내일 아침에 해!!!


• 지속적으로 서버에 빌드한 결과물을 배포해서 확인할 수 있는
환경 및 체계 마련하고 빠르게 자주 배포가 될 수 있도록 시스
템을 구성해야 함
개발계

검증계

개발자
형상항목CHECKOUT

작업
요청

N

현업/
IT


COMPILE
대상
Y
COMPILE
성공

운영계

검증계

N

COMPILE
대상
Y
COMPILE
성공

N

Y

N

N

Y

COMPILE
대상
Y
COMPILE
성공

Y

PACKAGING

PACKAGING

DEPLOY
N

PACKAGING

DEPLOY

DEPLOY

N

단위테스트
성공
Y
검증계이관요청
검증계이관
승인
N

통합테스트
성공
Y

이관 종료

운영계이관요청

Y

이관 종료

운영계이관
승인
N
이관 종료

Y

N

• 테스팅에 대한 인식 전환 필요
• TDD 방법론까지는 아니더라도 단위 테스트를 자동화하고 사람에
의한 테스트가 아닌 시스템에 의한 자동 테스팅 환경을 확보하는
것이 중요
• 지속적 통합에서 가장 설득하고 적용하기 어려운 부분 중 하나로
기술적인 문제가 아닌 절차와 인식의 문제임
테스트는 단위 테스트 / 통합 테스트 /
인수 테스트 기간에 하고 지금은 개발
에 전념 해야겠다.

…
개발이 지연됐네. 어차피 테스팅 기간
에 개발하면 되니깐 그때까지는 여유
가 있네

• xUnit, Cactus, TestNG 등의 테스트 도구를 이용해서 용도에 맞는
자동화 수행
• 코드 커버리지 도구를 이용해서 단위 테스트가 전체 어플리케이션
의 어느 부분까지 적용 되었는지 지속적으로 확인하기
• Checkstyle, PMD, FindBugs와 같은 소스 코드 검사 도구를 이용해
서 자동화 수행
• Unit 테스트를 위한 테스트 프로그램 개발을 시간 낭비라고 생각
해서는 안됨. 테스트 자동화를 통해 테스트 노력을 10%만 줄여도
큰 성과라는 생각으로 접근 해볼 필요 있음

Unit 테스트 결과

Code Coverage 결과

소스 품질 결과

• CI의 최종 목적은 자동화를 통해 소프트웨어에 대한 현황과 피
드백을 지속적으로 받는 것임
• 개발 환경에서 개발자 혹은 관리자들이 가장 많이 사용하는 도
구와 CI 도구를 연동할 필요 있음
• 레포팅과 피드백을
#139 차 CI 작업에서 단위 테스트 실패
율이 높던데 확인 했어?

네. 이클립스 Mylyn에서 결과 보고 확
인 중이에요. 다음 차수 CI 작업에서는
해결될겁니다.


• 결과를 체계화 하기 위해 레포팅에 대해서 고려
• 빠른 피드백을 받기 위해 다양한 디바이스 혹은 도구와 연계해
서 별도의 작업 없이도 결과를 쉽고 빠르게 확인 할 수 있도록
환경 마련
• 피드백이 스팸으로 인식하지 않도록 필요한 사람에게 정확한
내용을 전달 할 수 있도록 설계 필요
• 개발자가 많이 보는 개발툴, 이메일, 아웃룩 (RSS), 웹브라우져
같은 도구와 CI 도구를 연계 필요

Outlook 연동

개발툴 연동

E-mail 연동

2.8 더욱 발전을 위해서
• CI는 특정한 제품 및 솔루션이 아닌 ‘개발자’를 자동화하기 위한
일련의 생산성 향상 행위임
• 허드슨/젠킨스 등에 제약을 받지 말고 좀 더 발전적인 모습으로
응용해 나갈 필요 있음

통합개발환경
(Eclipse)

CI
(Hudson/Jenkins)

Issue Tracking
(Redmine)

Version Control
(Subversion,Git)

Build
(MAVEN/ANT)

Collboration
(Groupware/SNS)


3

어떤식으로 활용하고 있는가?
3.1 OKJSP
3.2 NHN

3.3 SK C&C

3.1 OKJSP – Jenkins 이용
• OKJSP 블로그인 http://okjsp.tistory.com/tag/hudson 에 접속해
보면 Hudson과 관련해서 OKJSP에 적용한 내용을 볼 수 있음
• http://www.okjsp.pe.kr:8080/ 에 접속해 보면 OKJSP의 Hudson
Dashboard를 볼 수 있음


3.2 NHN – HUDSON 이용
• 2011년 JCO 컨퍼런스에서 ‘오픈소스를 활용한 NHN 배치 처리
플랫폼’ 세션에서 HUDSON을 이용한 배치 어플리케이션 관리
에 대해서 소개하고 있음
• http://www.slideshare.net/knight1128/batch-8508863 에서 발
표 자료 확인할 수 있음
• 주로 CI 도구 보다는 배치 어플리케이션에 대해선 스케쥴러 기
능으로 활용
• 업무 요건을 맞추기 위해 HUDSON 플러그인을 개발해서 활용
• 빌드, 테스트, 배포라는 측면에서 잘 설명되어 있음


3.3 Big 3 SI 기업
• Big 3 SI 기업에서 기존 Waterfall 방식이 아닌 Agile 방법론을
프로젝트에 적용하고 있음. (Waterfall + Agile 형태)
• 개발 표준 및 CI 도구 적용은 거의 필수적인 대세로 정착하고
있는 상황임
• Agile 방법론 특히 CI는 일반 소프트웨어 개발 뿐만 아니라 SI
프로젝트에서도 필수 방법론의 일부로 인식되고 있음

SK C&C Agile 방법론


삼성 SDS AnyFrame

LG CNS 뱅킹 플래폼

참고 자료
•
•
•
•

허드슨을 이용한 지속적 통합, 인사이트, 2012
Software Secrects : Why Software Projects Fail. Apress. 2005
지속적인 통합, 위키북스, 2007
NHN 사례 : http://www.slideshare.net/knight1128/batch8508863
• SK C&C Agile 방법론 :
http://www.slideshare.net/k16wire/agile-practices-v10
• LG CNS 스마트 뱅킹 플랫폼 :
http://www.entrueworld.com/html/program/download/EW201
1_Track%201_Session%203.pdf


Demo

Q&A

“지속적 통합은 사람을 위한 것
지속적 통합을 하기 위해
사람을 희생 시켜서는 안됨”

허드슨을 이용한 지속적 통합 (Continuous Integration)

Recommandé

Recommandé

Contenu connexe

En vedette

En vedette (20)

허드슨을 이용한 지속적 통합 (Continuous Integration)