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

Using Hudson / Jenkins

“Continuous Integration”

2013.11.18

장윤기 ([email protected])

2 | Copyright 2013. Created by Yoonki Chang ([email protected])

목차

1.지속적 통합 이해하기

2.스스로 적용하기

3.다른 사람들의 활용 방식

4.질의 응답

지속적 통합 이해하기

1 1.1 왜 소프트웨어 프로젝트는 실패하나요?

1.2 실패를 줄일 수 있나요?

1.3 또 배워야 하나요?

1.4 무엇부터 어떻게 시작할까요?

1.5 최종 목표는 무엇인가요?


1.1 왜 소프트웨어 프로젝트는 실패하나요?

• 소프트웨어 산업과 다른 산업과의 차이점

* 출처 : Software Project Secrets. Why Software Projects Fail. Apress 2005

i. Software Is Complex

ii. Software Is Abstract

iv. Technology Changes Rapidly

vi. Technology Is a Vast Domain

iii. Requirements Are Incomplete

v. Best Practices Are Not Mature

vii. Technology Experience Is Incomplete

ix. Repetitive Work Is

Automated

viii. Software Development Is

Research

x. Construction Is Actually Design

xi. Change Is Considered Easy

xii. Change Is Inevitable


12 P

ract

ices

of eXtrem

e P

rogra

mm

ing


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

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 도구

<<인식 전환>>



• 위험을 줄여준다. • 특정 소스 코드의 컴파일 오류로 전체 소프트웨어 컴파일이 되지 않는 문

제를 빠르게 대처할 수 있음

• 반복적인 수작업을 줄여준다 • 개발자의 반복적이고 지루한 작업을 자동화하여 개발자는 개발에만 집중

할 수 있도록 함

• 코드의 변경에 대해 자동적으로 단위 테스트 및 영향 분석을 레포팅하고 이를 통해 소프트웨어의 품질을 향상 시킬 수 있음

• 언제 어느 때라도 배포할 수 있는 소프트웨어를 생성해낸다 • 빌드와 배포를 반복적으로 수행함으로 소프트웨어를 테스트할 수 있는

기회를 더욱 높일 수 있으며 이로인해 소프트웨어 품질이 높아짐

• 문제 상황 발생시 이를 빠르게 피드백 받고 즉각 처리할 수 있는 환경을 마련함

• 프로젝트 가시성을 좋게 한다

• 소프트웨어 제품에 대해 보다 큰 자신감을 갖게 해준다.


• 우리가 하는 일을 줄여줄 수 있다면 도구를 배우는 것을 두려워 해서는 안됨

도보 이동 대중교통 이동 자가용 이동

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

• 소요시간 : 19분 • 총거리 : 2.0 km

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

1.3 또 배워야 하나요?


• 어렵게 생각하지 말고 쉽게 본인이 필요하다고 생각되는 영역부터 하나 하나 적용해 보는 것이 좋음

• CI 도구를 개발자를 통제하기 위한 도구로 생각해서는 안되며 생산성 향상을 위한 도구로 사용해야 함

스스로 해야 할 것 1. 쉬운 CI 도구 선정 2. 빌드 자동화 (형상관리 + ANT / MAVEN) 3. 배포 자동화 (TOMCAT, FTP 등) 4. 테스트 자동화 (Junit 등) 5. 소스 코드 품질 검사 자동화 (PMD 등) 요구해야 할 것 1. CI 적용을 위한 시간 확보 2. 배우기 위한 자료 (책, 교육 등) 3. 형상 관리, CI 도구 등을 위한 장비 확보

개발자 측면 스스로 해야 할 것 1. 인내력을 가지고 기다림 2. CI는 생산성 향상 도구 (통제 도구 아님) 3. CI를 위해 투자하는 시간, 돈 4. 고성능 하드웨어 장비를 지급하는 여유 요구해야 할 것 1. 개발자 인식 전환 2. 단순 반복 작업이 아닌 생산적인 작업에

시간을 투자 3. 가치를 높이기 위한 노력

관리자 측면

1.4 무엇부터 어떻게 시작할까요?


• CI 도구는 최초 고려된 목적 외에 다양한 형태로 확대되고 있음

• CI 도구를 적용할 때에는 목표와 목적을 정확히 하고 로드맵에 따라 순차적으로 적용해갈 필요가 있음

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

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

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

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

인식 전환 및 기초환경 마련

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

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

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

환경 마련

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

9.단계별 레포트 자동화

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

통합 관리 체계 확보

‘나’를 위한 자동화

1.5 최종 목표는 무엇인가요?

스스로 적용하기

2 2.1 CI 사용을 위한 PATH

2.2 CI 도구 선택하기

2.3 형상관리 중심으로 작업하기

2.4 빌드 자동화 하기

2.5 배포 자동화 하기

2.6 테스팅 자동화 하기

2.7 레포팅 및 피드백

2.8 더욱 발전을 위해서


Iteration

Planning

2.1 CI 사용을 위한 PATH

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

시작 적용 목표 수립 적용 단계 수립 적용 방안 마련 CI 도구 선택

CI 설치

형상관리 설치 빌드 연동 배포 연동

기능 테스트 연동

품질 검사 연동

레포팅 결과 피드백

종료

CI 작업 정의 소스코드 커밋 최신 코드 업데이트

App 개발 단위 테스트 개발 (Junit)



• 한번 선택한 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 도구는 빌드 기능을 제공하지 않음

배포 서버

빌드 서버

Hudson Master

Deploy Agent

Deploy Script

빌드 요청

CHECKOUT

COMPILE

PACKAGING

SEND

대상 서버

Hudson Slave

Deploy Script

DEPLOY

형상 관리 서버

1

2

3

4 5

6

7

8

9



• 배포는 소프트웨어를 서비스하기 위한 가장 중요한 단계이며 서비스 하기 이전 개발자/설계자/관리자/고객에 의한 테스트를 위한 중요 항목임

우리 프로젝트는 배포는 밤 12시에 한번만 한다. 밤 12시 이후에 테스트하던

지 내일 아침에 해!!!

개발한 프로그램을 운영 데이터로 테스트하게 서버로 배포 좀 해주세요



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

개발자

현업/ IT

작업 요청

운영계 검증계 검증계 개발계

형상항목CHECKOUT

검증계이관요청

PACKAGING

DEPLOY

COMPILE 대상

COMPILE 성공

Y

N

Y

N

단위테스트 성공

Y

N

검증계이관 승인

이관 종료

Y

N


운영계이관요청

PACKAGING

DEPLOY

COMPILE 대상

COMPILE 성공

Y

N

Y

N

통합테스트 성공

Y

N

운영계이관 승인

이관 종료

Y

N


PACKAGING

DEPLOY

COMPILE 대상

COMPILE 성공

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)

Version Control (Subversion,Git)

CI (Hudson/Jenkins)

Issue Tracking (Redmine)

Collboration (Groupware/SNS)

Build (MAVEN/ANT)

어떤식으로 활용하고 있는가? 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를 볼 수 있음

http://okjsp.tistory.com/tag/hudson

http://www.okjsp.pe.kr:8080/


3.2 NHN – HUDSON 이용

• 2011년 JCO 컨퍼런스에서 ‘오픈소스를 활용한 NHN 배치 처리 플랫폼’ 세션에서 HUDSON을 이용한 배치 어플리케이션 관리에 대해서 소개하고 있음

• http://www.slideshare.net/knight1128/batch-8508863 에서 발표 자료 확인할 수 있음

• 주로 CI 도구 보다는 배치 어플리케이션에 대해선 스케쥴러 기능으로 활용

• 업무 요건을 맞추기 위해 HUDSON 플러그인을 개발해서 활용

• 빌드, 테스트, 배포라는 측면에서 잘 설명되어 있음

http://www.slideshare.net/knight1128/batch-8508863





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/batch-8508863

• SK C&C Agile 방법론 : http://www.slideshare.net/k16wire/agile-practices-v10

• LG CNS 스마트 뱅킹 플랫폼 : http://www.entrueworld.com/html/program/download/EW2011_Track%201_Session%203.pdf


Demo


Q & A

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