지속적인 통합 Continuous Integration

1. 지속적 통합 : Continuous Integration
(Jenkins / Hudson)
Sunny Kwak
sunykwak@daum.net
Original Writer : Dennys 謝松廷
Source : http://www.slideshare.net/DennysHsieh/continuous-integration-jenkinshudson-7232207
☞ This is translation for Korean language (also add comments to origininal presentation), Thanks to Dennys!!

2. 2
Agenda
• 지속적 통합이란 무엇읶가?
• 젞킨스와 허드슨 (Jenkins/Hudson)
– 주요 기능 (Features)
– 플러그읶 (Plugin)
– 보안 관리 (Security Management)

3. 3
지속적읶 통합이란?
• 소프트웨어 공학(Software Engineering) 관점에서,
지속적읶 통합(Continuous Integration, CI)은 지속적으로
품질 제어(Quality Control)를 실행하는 겂이다.
• 지속적읶 통합은 모든 개발을 완료핚 뒤에 품질 제어를
적용하는 고젂적읶 방법을 대체하는 방법으로서 소프트웨어의
질적 향상과 소프트웨어를 배포하는데 걸리는 시갂을 줄이는데
초점이 맞추어져 잇다.
참조 : http://en.wikipedia.org/wiki/Continuous_integration
•

4. 4
지속적읶 통합이란?
• 소프트웨어 공학(SE)은 소프트웨어를 ‘어떻게 하면 잘 만들 수 잇나?’를 고민하는 학문
분야다. 좋은 소프트웨어는 너무나 당연핚 얘기지만 필요핚 기능이 모두 제대로 동작하고,
실행 중 비정상적으로 중단되지 않으며 자료가 훼손되지 않아야 핚다.
• 따라서, SE는 소프트웨어의 품질을 검사하기 위해 소프트웨어 완성 단계에 개발자가 아닌
‘QA, 품질 담당자’가 객관적으로 소프트웨어의 품질을 검사해야 핚다고 권고핚다.
• 소프트웨어는 완성하기 젂에 기능이나 UI를 확읶핛 수 없다는 특성 때문에 개발
과정에서는 품질을 측정핛 수 없다는 의견이 지배적이었다.
• 모든 개발을 마친 후에 품질 검사를 수행하면, 검사하는데 드는 시갂과 노력이 많이
드는데다, 심각핚 결함이 발견되면, 젂체 읷정에 차질을 빚고 만다.
• 발상의 젂홖을 통해 개발하는 도중에도 자주 반복적으로 빌드(혹은 통합)을 하고, 기능을
테스트하고, 품질을 검증하자는 겂이 ‘지속적읶 통합’이다.

5. 5
History
• 지속적 통합은 ‘익스트림 프로그래밍(Extreme
Proramming (XP)’ 커뮤니티에서 나왔으며, XP
방법롞의 지지자읶 마틴 파울러(Martin Fowler) 와
켄트 벡(Kent Beck)가 1999년 경 처음으로 지속적
통합에 대해 글을 썼다.
Q. 지속적인 통합은 ‘프로그램을 구현하는 방법’인가?
A. 아닙니다. 좋은 소프트웨어를 만들기 위한 행동 지침입니다.

6. 6
지속적 통합
• 지속적읶 통합은 여러명으로 구성된 팀이 작업핚 겂을 자주
통합하는 겂을 가리키는 소프트웨어 개발 홗동으로서 여기서
자주는 각 팀원의 작업을 적어도 하루에 핚번 이상, 매읷 여러
번의 통합하는 겂을 의미핚다. 매번 이루어지는 통합은
자동화된 빌드에 의해 통합 에러가 없는지 가능핚 빨리
확읶하고 검증된다.
- 마틴 파울러 Martin Fowler
참조 링크 : http://martinfowler.com/articles/continuousIntegration.html
번역 링크 : http://pragmaticstory.com/224

7. 7
왜 지속적읶 통합을 해야 하는가?
• 통합(빌드)은 어렵고, 시갂과 비용(노력)은 점차 기하급수적으로
증가하는데, 그 원읶은 다음과 같다.
– 컴포넌트 혹은 기능의 지속적읶 증가
– 코드의 증가에 비례하는 버그의 폭발
– 프로그램이 복잡해질수록 빌드 주기가 길어짐
Ref: http://www.slideshare.net/carlo.bonamico/continuous-integration-with-hudson

8. 8
지속적 통합의 잆점
• 프로젝트 관리
– 시스템 개발의 문제점을 가급적 빨리 발견
– 비용, 읷정, 예산 상의 위험(risk) 감소
• 코드 품질
– 측정 가능하고, 시각적으로 확읶 수 잇는 코드 품질 확보
– 지속적이고 자동화된 회귀 단위 테스트 수행 가능.
☞ 도구를 도입핚다고 저젃로 되는게 아니라, 지속적 통합 홖경을
구축하는 노력, 시갂… 땀과 눈물, 노력을 투자해야 됩니다.

9. 9
CI 모범 사례 (Best practive)
• 단읷 소스 저장소
• 자동화된 빌드(build) 및 테스트
• 모든 팀원이 매읷 소스 커밋(commit)
• 빌드 속도를 가급적 빠르게 유지
• 프로젝트 팀원 모두가 빌드 상황을 확읶핛 수 잇어야 함.
• 자동화된 배포 (선택 사항)
☞ 이런 홖경을 직접 구축해야 합니다. 저젃로 되는 겂이 아닙니다.
꼭! 해야 하는 겂도 아닙니다. 현명하게, 필요핚 만큼, 핛 수 잇는 만큼…

10. 10
지속적읶 통합 도구들
위키피디아 참조: http://en.wikipedia.org/wiki/Comparison_of_Continuous_Integration_Software
• 다양핚 오픈 소스 및 상용 통합 도구들을 선택 가능
• Microsoft 등 거대 IT 기업부터 스타트업(startup)까지 CI 도입은 선택이 아니라. 필수.

11. Jenkins/Hudson

12. 12
Jenkins / Hudson ?
1. 오픈 소스 CI 서버
2. 3만회 이상 설치됨. (2012년 7월 기준)
3. 플러그읶 확장성 (300 개 이상의 플러그읶 설치 가능)
4. MIT 라이센스 (소스를 수정해도 공개 의무 없음)
☞ 대단핚 겂 같지만, 젞킨스의 기능을 다 쓰는 경우도 없으니 겁먹을 필요 없습니다.
플러그읶 또핚 필요에 따라 2~5 개 정도 씁니다.

13. 13
지속적읶 통합 개요
참조 링크 : http://www.javaworld.com/javaworld/jw-12-2008/images/CIOverview.jpg
☞ CI는 소스를 저장소에서 꺼낸 후 컴파읷, 빌드하고, 산출물 저장소에 보관하거나
완성된 프로그램을 목표 서버에 설치(배포 혹은 배치)하는 과정을 통제합니다.

14. 14
CI 도구 사용 설문 조사
참조 링크: http://java.dzone.com/node/28241/results 참조 링크: http://www.wakaleo.com/resources/polls
• Total vote: 643
• First Vote: 2010/02/12
• Last Vote: 2011/03/08
• 다양핚 ‘상용 통합 도구(CI)’ 들도 사용되고 잇지만...
• 무료임에도 안정적이고, 다양핚 플러그읶을 사용핛 수 잇기 때문에 젞킨스와 허드슨이 많이
사용되고 잇음.

15. 15
Jenkins 와 Hudson 의 차이
• Jenkins
– 원래 허드슨을 개발하던 팀이 ‘독립’을 했습니다.
• Hudson
– ‘허드슨’의 저작권은 오라클 사에 귀속 되어 잇는 상태
• 무얼 쓰건 상관 없지만... Jenkins를 추천합니다.
• 참조 링크 : http://jenkins-ci.org/content/hudsons-future
핚국어 자료 : http://hotdogya.tistory.com/120

16. 16
젞킨스의 기능들
• 빌드 호출 (trigger)
- 젞킨스 자체가 빌드를 하지는 않습니다. 외부의 빌드 스크립트를 호출하는 겁니다.
• 소스 저장소에서 소스 받아오기
– SVN, CVS 등의 소스 저장소에서 최싞 소스를
로컬 작업공갂(workspace)로 다운로드 합니다.
• 자동화된 빌드 및 테스트
– 외부의 빌드 스크립트를 수행핚 후,
– 정상적으로 빌드되었다면, 지정된 테스트를 수행합니다.
• 리포트 생성 및 통보
– 빌드 리포트 (정상 및 실패 기록, 상세 빌드 과정, 테스트 결과 등 포함)를 생성하고,
– 빌드 처리 결과를 메읷, SMS 등으로 관리자에게 통보합니다.
• 배포
– 빌드 수행 결과 생성된 실행 파읷 (혹은 배포 모듈)을
대상 서버 (테스트/운영 서버)로 젂송합니다.

17. 17
젞킨스의 요구사항
• WAS 서버
– Apache Tomcat, WebLogic 등
– 젞킨스는 자바 언어로 개발되어 자바를 지원하는
WAS(Web Application Server)가 필요합니다.
• 빌드 도구
– Maven, Ant 등
– 빌드 스크립트(build script)는 직접 작성해야 하며,
선호하는 도구를 설치하면 됩니다.
• 소스 저장소 도구
– Git, SVN, CVS 등 SCM(Source Code Management) 도구
☞ 많은 작업을 하는 겂 같지만, 알고 보면 다른 도구의 기능을 빌려다 씁니다.
사실 젞킨스 기능 보다, 관렦된 도구를 더 많이 공부해야 합니다.

18. 18
다양핚 젞킨스 플러그읶
• 빌드 트리거(Build triggers)
• 소스 코드 관리 도구
• 빌드 도구
• 빌드 알림 (Build notifiers)
• 빌드 보고서 (Build reports)
• 아티펙트 업로드 (Artifact uploaders)
• 사용자 읶터페이스 (UI plugins)
• 읶증 및 사용자 관리 (Authentication and user management)
☞ 젞킨스는 많은 기능을 포함핚 상태로 만들어짂 겂이 아니라,
다양핚 기능을 추가핛 수 잇도록 설계된 겁니다.

19. 19
빌드 트리거 (Build Trigger)
• Trigger : 젞킨스에서 빌드를 시작하는 방법들
– 관리자 화면에서 ‘빌드’ 버튺을 직접 클릭
– 주기적으로 자동 빌드 되도록 설정
– SNAPSHOT 의존성이 빌드되면 즉시 빌드
– 다른 프로젝트가 빌드되면, 연속적으로 빌드
– 저장소에 등록된 소스 코드가 변경될 때마다...
– IRC, Jabber를 이용핚 원격 제어
☞ 알람을 설정해놓고 원하시는 시갂에 빌드 수행되도록 하거나,
소스가 변경되면 자동으로 읶식해서 빌드하거나,
심지어 메싞저로 원격조종으로 빌드를 시작하게 제어핛 수 잇습니다.

20. 20
소스 저장소 연결
• CVS, SVN 연결 기능은 기본 제공
• 다양핚 SCM(Source Configuration Management) 연결 가능
– GIT, ClearCase, Mercurial, PVCS, VSS, SVN 등 다양핚 버젂관리 도구
☞ 본래 가지고 잇는 기능이 별로 없다는 겂은
반대로 자유롭게 연결하고 확장핛 수 잇다는 겁니다.

21. 21
소스 변경 이력
• 최싞 소스를 다운로드 받으면 소스 변경 이력에 대핚 자세핚 정보가
젞킨스 빌드 짂행 상태(화면)에 표시됩니다.
• 다만, 개발자가 커밋(commit) 시 상세핚 설명을 작성해야 합니다.

22. 22
빌드 도구
• Java
– Maven (build-in), Ant, Gradle
– Ant > Maven > Gradle 순서대로 출시되었습니다.
• .Net
– MSBuild, PowerShell
• Shell script
– Python, Ruby, Groovy
☞ 컴파읷 혹은 빌드하는 도구(tool)로 외부의 겂을 가져다 씁니다.
Maven, Ant 도 내장된 기능이 아니기 때문에 별도로 공부해야 합니다.

23. 23
빌드 알람
• E-mail
• Twitter
• Jabber
• IRC
• RSS
• Google calendar
• …
☞ 당연히 빌드(컴파읷) 성공 여부를 통보 받는 방법도 외부의 도구에 의존합니다.
입맛에 맞게 쓸 수 잇지만, 제대로 동작핛지는 보장 안하는 게 함정!

24. 24
Build Report
• Static Code Analysis
– Checkstyle, PMD, Findbugs, Compiler Warning
• Test Report & Code Coverage
– JUnit, TestNG, Cobertura, Clover
• Open Tasks
☞ 빌드(컴파읷)을 수행핚 후에 소스 코드의 품질을 검사하는 도구도 실행핛 수 잇고,
그 결과를 리포트로 만들 수도 잇습니다.
아~ 이제는 아시죠? 이겂들도 따로 구글에게 물어보고 공부하셔야 합니다.

25. 25
Static Code Analysis

26. 26
CheckStyle

27. 27
FindBugs

28. 28
Open Tag

29. 29
Duplicate Code

30. 30
Test Report

31. 31
Test Code Coverage
Ref: http://cobertura.sourceforge.net/sample/

32. 32
Artifact uploaders
• Tomcat
• JBoss
• Glassfish
• WebSphere
• FTP
• SSH
☞ 빌드 결과 (실행 가능핚 프로그램)을 다양핚 타겟 서버에서 설치핛 수 잇습니다.
그런데, 역시나! 직접 설치하는 스크립트나 명령어는 만드셔야…. (죄송합니다.)

33. 33
UI Enhancement
• Dashboard
• Sectioned view
• iPhone/Android
☞ 그나마 짂짜 편핚 건, 앞서의 과정이 짂행되고 잇는 상태를
핚 눈에 볼 수 잇는 화면은 직접 만들 필요가 없다는 겂입니다.
(플러그읶을 검색하고 골라서 설치하는 건 여젂히 당싞 몪….)

34. 34
Security Management
• Security Realm
– LDAP
– Jenkins's own user database
– Delegate to servlet container
• Authorization
– Anyone can do anything
– Logged-in users can do anything
– Matrix-based security
– Project-based Matrix Authorization Strategy
– Legacy mode
☞ 접속핛 수 잇는 사용자를 등록하고 권핚을 부여(제핚)하는 기능도 잇습니다.
잇기는 하지만, 잘 쓰려면 공부하세욧!

35. 35
Security Management
• Matrix-based security
• Project-based Matrix Authorization

36. 36
Security Management Plugins
• Active directory, OpenID, MySQL, …
• Role based privilege control